Framtagning av process för automatisk hantering av uppdatering och generering av dokumentation på Medius AB

Institutionen för datavetenskap

Department of Computer and Information Science

Examensarbete

Framtagning av process för automatisk

hantering av uppdatering och generering

av dokumentation på Medius AB

Mikael Modin

Reg Nr: LIU-IDA/LITH-EX-A–10/005–SE Linköping 2010

Handledare: Mikael Svensson

Medius AB

Fredrik Spira

Medius AB

Examinator: Kristian Sandahl

ida, Linköpings universitet

Institutionen för datavetenskap Linköpings universitet

Avdelning, Institution Division, Department

Software and Systems

Department of Computer and Information Science Linköpings universitet

SE-581 83 Linköping, Sweden

Datum Date 2010-18-003 Språk Language  Svenska/Swedish  Engelska/English   Rapporttyp Report category  Licentiatavhandling  Examensarbete  C-uppsats  D-uppsats  Övrig rapport  

URL för elektronisk version

http://www.ida.liu.se http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-54516 ISBN — ISRN LIU-IDA/LITH-EX-A–10/005–SE Serietitel och serienummer Title of series, numbering

ISSN —

Titel Title

Framtagning av process för automatisk hantering av uppdatering och generering av dokumentation på Medius AB Författare Author Mikael Modin Sammanfattning Abstract

Examensarbetet utfördes åt företaget Medius AB. Arbetet bestod av att designa en ny process för Medius nuvarande och framtida dokumentationsbehov.

För att göra detta behövde tre steg slutföras. Först skulle information om dagens dokumenthantering inhämtas, vilka dokument skrivs av vem och för vem skrivs de och vilka behov finns det som idag kanske inte fylls. En grov lista över ön-skad funktionalitet togs också fram och därefter designades en process som klarar av att fylla alla dessa krav och behov. Sist skulle en lista över verktyg som behövs för den nya processen tas fram och en undersökning om vad som finns och vad som behöver byggas från grunden skulle genomföras. Alla dessa steg har genom-förts och den nya processen har utvärderats genom enkäter till medlemmar ur ett antal olika fokusgrupper.

Resultatet av utvärderingen tyder på att det är lite arbete kvar att genomföra innan processen är redo att börja implementeras hos Medius, och dessutom behöver alla verktyg implementeras. När detta väl är klart kan den nya processen dock hjälpa Medius AB att lösa flera av de nuvarande problemen eller bristerna.

Nyckelord

Abstract

The thesis work was done for Medius AB. The work consisted of designing a new process for current and future documentation-related needs of Medius.

To do this, three steps needed to be completed. First, information on the com-pany’s current information management needed to be gathered, written documents and their authors needed to be accounted for, and any requirements not filled by the current documentation process needed to be listed. A rough list of desired functionality was drafted, and after that, a process to fit these requirements was designed. A list of all the tools needed for this new process was written, as was a study of available tools that could potentially be modified to fit the company’s needs, and an assessment of what tools should be written from scratch. Finally, this new process was reviewed by selected members from focus groups.

The result of the review points can be summarised as follows: More work is needed before the process can be introduced at Medius, besides all the tools that need to be implemented or modified. Once this is done, the new process can help Medius solve several of their current problems..

Sammanfattning

Examensarbetet utfördes åt företaget Medius AB. Arbetet bestod av att designa en ny process för Medius nuvarande och framtida dokumentationsbehov.

För att göra detta behövde tre steg slutföras. Först skulle information om dagens dokumenthantering inhämtas, vilka dokument skrivs av vem och för vem skrivs de och vilka behov finns det som idag kanske inte fylls. En grov lista över önskad funktionalitet togs också fram och därefter designades en process som klarar av att fylla alla dessa krav och behov. Sist skulle en lista över verktyg som behövs för den nya processen tas fram och en undersökning om vad som finns och vad som behöver byggas från grunden skulle genomföras. Alla dessa steg har genomförts och den nya processen har utvärderats genom enkäter till medlemmar ur ett antal olika fokusgrupper.

Resultatet av utvärderingen tyder på att det är lite arbete kvar att genomföra innan processen är redo att börja implementeras hos Medius, och dessutom behöver alla verktyg implementeras. När detta väl är klart kan den nya processen dock hjälpa Medius AB att lösa flera av de nuvarande problemen eller bristerna.

Tack

Jag vill tacka flera personer som stöttat mig i mitt arbete med den här rapporten. Min examinator, mina handledare och resterande personal på Medius som svarat på oräkneliga frågor och hjälpt mig att utvärdera den nya processen. Jag vill även tacka Joel Hinz som svarat på otaliga språktekniska och grammatiska frågor.

Innehåll

2.3 Dokumentation, långa projekt och Scrum . . . 14

3 Nuvarande process 19 3.1 Scrum på Medius . . . 19

3.2 Personal och dokument . . . 20

3.3 Externa dokument . . . 23

3.4 Dokumenttyper . . . 24

3.5 Nuvarande verktyg . . . 25

3.6 Utvärdering . . . 29

4 Ny process 31 4.1 Hantering av uppdateringar av dokument . . . 31

4.2 Generering av dokument från delar . . . 34

4.3 Implementering . . . 36

4.4 Implementeringens delar . . . 40

5 Utvärdering av nya processen 45 5.1 Jämförelse med existerande process . . . 45

5.2 Risker . . . 46

5.3 Åsikter och återkoppling . . . 46 ix

6 Diskussion 51

6.1 Förbättringar av den nya processen . . . 51

6.2 Skillnader mellan utvärderingssvar . . . 53

6.3 Införandeplan . . . 53 6.4 Övriga funderingar . . . 54 7 Slutsats 57 Litteraturförteckning 59 A Funktionalitetslista 63 B Svar från utvärdering 65 B.1 Person A, Utvecklare . . . 65

B.2 Person B, Utvecklings- och marknadsansvarig . . . 67

B.3 Person C, Konsult/Leverans . . . 68

B.4 Person D, Marknadsföring . . . 69

B.5 Person E, Chef / Person på högre position . . . 71

Figurer

2.1 Översikt över Scrum-processen . . . 11

3.1 Ett enkelt flödesschema för när ett förslag har accepterats av pro-duktrådet . . . 21

3.2 Delarna av .NET ramverket . . . 28

4.1 En översiktsbild av dokumentuppdatering med den nya processen . 31 4.2 Scenario 1 . . . 32

4.3 Scenario 2 . . . 33

4.4 Scenario 3 . . . 33

4.5 Scenario 4 . . . 34

4.6 En översiktsbild av dokumentgenereringen med nya processen . . . 34

4.7 Scenario 5 . . . 35

4.8 Scenario 6 . . . 35

4.9 Kopplingar för dokumentuppdatering i nya processen . . . 36

Kapitel 1

Inledning

Det här kapitlet ger en kort introduktion till rapporten, bland annat dess bakgrund och syfte, samt en beskrivning av rapportens övriga delar.

1.1

Bakgrund

Medius AB[17] är ett företag som hjälper sina kunder att effektivisera processer och arbetsflöden med hjälp av IT. De har dessutom konsultverksamhet och säljer det egenutvecklade webbaserade ärendehanteringssystemet MediusFlow. MediusFlow kompletterar existerande affärssystem genom att ta hand om de ärenden

existerande system inte kan. MediusFlow har sin grund i ett tidigare examensarbete[12] men har sedan dess växt mycket och har idag ett flertal stora kunder som användare[19].

1.2

Problemställning

I dagsläget skrivs vissa dokument i början av utvecklingen och uppdateras inte så ofta som de borde. Andra dokument skrivs först när en kund ber om att få dem och uppdateras inte förrän en annan kund ber om att få ett exemplar. Detta kan leda till att funktionalitet hamnar i sprickorna och tappas bort i dokumentationen samt att hela dokumentet måste gås igenom när en kund ber om att få det, vilket leder till att stora delar ofta behöver skrivas om. Är det en stor kund sker allt detta under stress vilket leder till att den mänskliga faktorn får större inverkan och till att risken för fel ökar.

1.3

Syfte

Rapportens syfte är ta fram en implementationsplan över hur Medius skulle kunna automatisera sin hantering av uppdateringar av dokument. Den ska innehålla:

• Överblick över hur processen fungerar i dagsläget. 3

• Överblick över hur processen ska fungera.

• Lista över ny mjukvara som behöver implementeras.

• Lista över de förändringar som behöver genomföras i existerande mjukvara.

1.4

Metod

Arbetet delas upp i ett antal delar:

1. Genomgång av nuvarande process för att se vilka delar som ingår. 2. Framtagande av krav på vad den nya processen ska klara av, vad för

dokumenttyper som ska hanteras.

3. Undersökning av existerande verktyg och lösningar. 4. Design av den nya processen.

5. Beskrivning av de nya verktygen.

6. Beskrivning av förändringar i existerande mjukvara. 7. Utvärdering av design av den nya processen.

1.4.1

Nuvarande process

Det första steget är att se över hur Medius arbetar med sina dokument i dagsläget. Det finns ett antal dokument som rör ett antal olika delar av verksamheten vid olika tidpunkter. Frågor som ska besvaras är:

• Vilka dokument används? • Vad används de till? • När används de? • Av vem används de?

För att få tillräckligt med information om nuvarande rutiner tänkte jag främst använda mig av intervjuer med anställda på Medius. Då jag satt på Medius nästan hela tiden var det sällan ett problem att få intervjutid med personalen.

1.4.2

Krav på ny process

Jag behöver ta reda på vilka krav som ställs på den nya processen; vad den måste klara av för att Medius ska bli nöjda.

1.4 Metod 5

1.4.3

Ta fram ny process

När jag har tagit reda på vilka delar som finns i den nuvarande processen kan jag börja undersöka hur den kan förbättras:

• Vilka dokument behöver vara uppdaterade? • Vilka bör uppdatera dem?

• När bör de uppdateras?

• Hur bör de uppdateras? Manuellt, automatiskt eller en blandning?

Med en ny process klar vet jag vilka delar som i dagsläget inte finns och då kan jag se om det bör skrivas nya verktyg för att fylla de tomma rutorna eller om det går att spara tid genom att lägga till funktionalitet i existerande system. Den önskade funktionaliteten som togs fram listas i A

1.4.4

Verktyg

De nya verktygen ska designas. För varje verktyg ska två frågor besvaras: • Vad är verktygets uppgift?

• Hur ska verktyget utföra sin uppgift?

I de fall där man kan spara tid genom att lägga till funktionalitet i existerande mjukvara istället för att implementera helt nya verktyg behöver dessa förändringar specificeras. För varje förändring ska dessa frågor besvaras:

• Vilket system ska modifieras? • Vad för förändring ska genomföras? • Hur ska förändringen genomföras?

1.4.5

Fokusgrupper

Då exjobbet görs på ett företag och tiden spenderas på företaget har jag möjlighet att ta hjälp av fokusgrupper under arbetet. Fokusgrupperna är

• Utvecklare

• Marknadsförare/Säljare • Konsulter/Leveranspersonal • Chefer/Personer i högre positioner

Det finns möjlighet till personlig kontakt med nästan alla vid behov så jag hade inte så stora problem med intervjuer och utvärdering.

1.4.6

Utvärdering

Då ingen slutgiltig implementering sker går det inte att göra en slutgiltig ut-värdering. Det går dock att teoretiskt utvärdera den nya processen och göra en uppskattning av om den ser ut av att de behov Medius har. Då jag sitter på före-taget och har möjlighet till utvärdering med hjälp av fokusgrupperna kommer jag att göra genomgångar av den nya processen med medlemmar ur fokusgrupperna för att samla in åsikter.

1.5

Målgrupp

Rapporten är menad att läsas av tekniskt kunniga personer som vill ha en översikt över hur ett system för automatisk dokumenthantering kan implementeras.

1.6

Avgränsningar

Rapporten kommer bara att ta upp överblick och övergripande design, implementering kommer endast att ske i mån av tid.

1.7

Källkritik

Jag kommer att arbeta med mjukvara från Microsoft vilket innebär dokumentation från Microsoft. Jag förutsätter att dokumentationen från Microsoft är partisk och kommer att ta all information som inte är teknisk med en nypa salt. Mjukvaran jag kommer att arbeta med, Visual Studio 2010 samt Team Foundation Server 2010, är i tidiga utgåvor, beta-versioner, vilket innebär att den tekniska dokumentationen kanske inte heller går att lita på helt.

När det gäller källor för programmering och nya tekniker är det svårt att hitta någon “officiell”, man får pussla ihop en egen bild från olika källor och se vad som fungerar. Detta gör att det ibland är svårt att ange tillförlitliga källor.

1.8

Översättningar

Inom mjukvaruutveckling är den överväldigande majoriteten av dokument och system på engelska vilket gör att de facto-standardspråket är engelska. I den här rapporten är alla engelska termer översatta men det finns fotnoter med de engelska termerna för att förtydliga vilket som översatts om det skulle råda någon förvirring.

1.9

Disposition

Kapitel 2 Teorikapitlet, Utvecklingsmetodiken Scrum och hur den förhåller sig till dokumentation beskrivs.

1.9 Disposition 7

Kapitel 4 Beskrivning av den nya processen, hur den bör fungera och vilka delar som ingår.

Kapitel 5 Teoretisk utvärdering av den nya processen. En processbeskrivning skickades till ett antal personer som fick uttala sig om de tror att den kommer fungera tilfredställande och resultatet sammanställs här.

Kapitel 6 Diskussion kring vad jag kommit fram till. Bra och dåliga sidor med den nya processen, arbete som behöver sluföras innan den är redo att införas och ett antal andra ämnen avhandlas.

Kapitel 7 Slutsatsen som nåtts. En väldigt kort sammanfattning av resultatet jämfört med målet som beskriver om jag anser att jag har lyckats.

Sist i rapporten hittas ett antal bilagor

Bilaga A Lista över önskad funktionalitet i den nya processen. Bilaga B Svar till utvärderingen som bas i kapitel 5.

Kapitel 2

Scrum

Traditionell mjukvaruutveckling sker ofta enligt “Vattenfallsmodellen” som är baserad på Taylorism[16], arbetet sker linjärt och i separata steg.

• Inhämtning av krav • Arkitektur

• Design

• Implementation • Test

Metodiken känns naturlig för människor, börjar man bygga en bro vill man först veta vad den ska klara av, sedan kan man börja klura över vilken typ av bro man vill ha. När man vet det kan man ta fram en ritning och när den är färdig bygga bron. När byggandet är klart testar man den och sedan kan bron öppnas för allmän användning.

Det fungerar dock inte särskilt bra i stora delar av mjukvarubranschen för att det faller på en väldigt viktig punkt; inhämtning av krav. Ska man utveckla system för en kund finns det fyra stora risker[34]:

• Otydliga krav som inte förstås helt förrän man är mitt i utvecklingen. • Användare som inte vet vad de vill ha förrän de ser en första version. • Krav som ändras under utveckling.

• Nya verktyg och tekniker gör det svårt att förutsäga hur marknaden kommer att se ut när projektet är klart.

Det skulle vara ganska jobbigt för en brobyggare om denne när bron är halvfärdig får veta att den istället för bilar ska byggas för tåg. Det är fortfarande en bro men den ska klara andra typer av belastningar, vilket föga förvånande ger ganska stora problem. Det här är dock något som mjukvaruutvecklare får leva med när de

utvecklar åt någon, vilket leder till att traditionell utveckling inte fungerar i alla lägen. Det förutsätter också att alla bra idéer finns i början av projektet så att arkitektur och design kan utföras med dem i åtanke, i verkligheten händer detta sällan utan idéer kommer lite när som under projektets livstid. När man blandar in människor får man “aha”-effekten, när man ser något fungera i sin helhet kommer man genast på många sätt det skulle kunna göras bättre[33].

På den andra änden av skalan över utvecklingsmetodiker finns allt-samtidigt-utveckling. Då gör man allt samtidigt: arkitektur, design, implementation och test tills produkten är klar och kan levereras. Det här är en otroligt effektiv metod, det tog en person två år att skriva en databas för Mantisse-projektet, en objektdatabas som används för att driva verk för behandling av kärnkraftverksavfall. Med mindre än 50 000 rader kod var det enligt kärnkraftingengörerna den snabbaste och stabilaste databasen de någonsin använt. IBM har dokumenterat en variant av detta arbetssätt som de anser är den mest produktiva av alla metodiker. Den har dock en stor nackdel: den skalar inte alls. Det går inte att ha mer än 1-2 personer som arbetar med ett projekt. Det tog en grupp kompetenta utvecklare tre år att sätta sig in i Mantisse-databasen innan de kunde underhålla den[34].

Steget före allt-samtidigt kallas parprogrammering; två programmerare utvecklar en komponent tillsammans vid en dator. Det har visat sig ge bättre kod (snabbare, stabilare och mer flexibel) än två utvecklare som programmerar på var sitt håll, de lägger ner 20 procent mer arbete men hela arbetet går 40 procent snabbare att slutföra[3]. Men den skalar också dåligt[34].

På grund av bristerna hos ovanstående metodiker togs Scrum fram. Prototyp-processen skapades av två japaner, Takechi och Nonaka, runt skiftet 80-/90-talet och formaliserades av en amerikan, Sutherland[33]. Flera andra har hjälpt till men dessa var huvudpersonerna bakom metodiken.

I stora drag arbetar man enligt det här flödet:

2.1

Ren Scrum

Scrum är en av de följsamma utvecklingsmetodikerna, gjord för att öka synergi-effekten mellan olika utvecklares arbete och starka sidor samt öka fokus hos utvecklingsgrupperna. Den gör detta genom att hämta erfarenheter från forskning inom artificiellt liv; genom att hålla sig närmare kaos kan man öka takten för systemets utveckling. Den tar även delar från robotarkitekturer; genom att ha en samling enkla regler får man en miljö som möjliggör självorganiserande

organisationer av utvecklingsgrupper som bygger system med föränderlig arkitektur.[34]

2.1.1

Roller i Scrum

I Scrum finns ett antal roller: Scrum-mästaren, produktägaren och gruppen. Huvud-tanken med Scrum är att gruppen ska vara fokuserad - så få störande element ska ha möjlighet att påverka dem som möjligt. Personer klassas som en av två typer, kycklingar och grisar, och anledningen illustreras bäst med en liten historia:

Kycklingen frågar grisen om denne vill vara med och öppna en restaurang. “Visst” svarar grisen och undrar vad den ska heta. “Fläsk och ägg” svarar

kyck-2.1 Ren Scrum 11

Figur 2.1. Översikt över Scrum-processen[30]

lingen, grisen funderar lite och säger sedan “Jag tror inte jag vill vara med och öppna en restaurang med dig. Du kommer att vara involverad medan jag kommer att vara förpliktigad” [4].

Tanken lyder att utvecklarna i gruppen är grisar; de är förpliktigade att utföra det arbete som krävs för att produkten ska bli klar. Övriga intressenter är kycklingar, de är bara involverade. Denna tydliga gränsdragning är karakteristisk för Scrum. Kycklingarna framställs som störande element, nästan hot, mot grisar-nas arbete och kycklingargrisar-nas inblandning ska begränsas så mycket som möjligt.

2.1.2

Arbetsgång

Allt som ska göras - ny funktionalitet, buggfixar och andra uppgifter - läggs i en implementationslistasom är en prioriterad lista som ska innehålla allting, finns något inte i implementationslistan ska det inte göras. Gruppen väljer ut vilka buggar och funktioner som ska ingå i en specifik sprint(se avsnitt 2.1.3) och varje sprint ska avslutas med något levererbart. Till sin hjälp för att göra detta har de information om hur kritiskt problemet är, och hur stor nytta en ny funktion skulle göra. Detta vägs mot hur lång tid som behövs för att implementera rättelsen eller funktionen.

Produktägaren Produktägaren för alla kycklingars talan. Detta har den stora fördelen att gruppen och Scrum-mästaren bara behöver ha kontakt med en person vilket innebär mindre arbete för gruppen. Det är produktägaren som prioriterar buggfixar och funktioner i implementationslistan.

Scrum-mästaren Det ligger på Scrum-mästaren att ta bort alla hinder som kan störa gruppen i deras arbete. Han ska jobba nära produktägaren och se till att alla intressenters önskemål tas i beaktande under utvecklingen. Det ligger också på Scrum-mästaren att hålla koll på gruppen så att den

jobbar produktivt och i enlighet med Scrum, kommer på alla dagsmöten och liknande aktiviteter. Problem mellan personal kan stå för runt 50% av all produktionsförlust[33, p. 17] så det är viktigt att Scrum-mästaren löser problem fort. Scrum-mästaren har också till uppgift att uppdatera diagrammet över återstående tid så att alla kan se hur gruppen ligger till. Gruppen Gruppen som arbetar med alla sprintar bör bestå av 5-10 personer,

olika källor[9, 33] säger olika saker men de håller sig inom det intervallet. Då gruppen utför allt arbete med sprinten design, implementation och test -så bör alla i gruppen ha kunskaper inom samtliga områden.

All funktionalitet i implementationslistan specificeras som PBI:er eller buggar beroende på om det är ny funktionalitet eller en rättning. Under varje sprint delas de PBI:er som ingår upp i mer avgränsade och specificerade SBI:er.

2.1.3

Sprint

En sprint är en intern version, en specifik samling buggfixar och nya funktioner att implementera under ett specifikt tidsintervall som i normala, och även Medius, fall är en månad. Det går att ta bort en rättning eller en funktion ur en Sprint men man ska inte flytta datumet den slutar.

Det finns några olika möten som hålls med olika intervall under en sprint. Dagligt möte Varje dag börjar med att gruppen, Scrum-mästaren och

produk-tägaren samlas för att alla i gruppen ska svara på tre frågor: vad gjorde jag igår, vad jag ska göra idag och vilka hinder har jag framför mig?

Andra personer får vara där men bara personer som ska utföra något arbete i sprinten får prata. Dessa möten ska hållas kortare än 15 minuter, ett enkelt trick för att hålla nere tiden är att alla står upp, börjar folk bli trötta i benen har mötet varit för långt. Under dagsmöten ska inte problem lösas, de ska bara noteras, och efter mötet kan personer samlas för att försöka lösa dem gemensamt. Rosing och Janoff hävdar dock att man inte behöver ha dessa möten varje dag utan att det räcker med 2-3 gånger per vecka[13].

Utvärderingsmöte När sprinten är slut ska den utvärderas och visas upp. På det här mötet är alla intressenter inbjudna och

produktägaren leder mötet. Under den första halvan av det maximalt fyra timmar långa mötet kan det som åstadkommits i sprinten visas upp och man kan se över marknaden, ekonomin och andra faktorer som spelar in på

2.2 Distribuerad Scrum 13

utvecklingen och kan få produktägaren att ändra på prioriteringen av ny funktionalitet eller buggfixar. När den här delen av mötet är avklarad går alla kycklingar ut och Scrum-mästaren tar över. Under den andra halvan av mötet leder Scrum-mästaren mötet och nästa sprint planeras efter de nya prioriteringarna.

Återblicksmöte Efter att utvärderingsmötet tagit slut diskuterar gruppen och Scrum-mästaren hur arbetet gått, och om något i processen behöver ändras till nästa sprint.

När utvärderingsmötet tagit slut påbörjas arbetet med nästa sprint. Detta fortsätter tills produkten är klar för leverans. Då funktionalitet prioriteras efter hur viktig den är minskar risken för att gruppen implementerar onödig

funktionalitet. Eftersom runt hälften av all funktionalitet i program inte används[33] kan utvecklingstiden ofta kortas ned markant.

Problem upptäcks och förmedlas under de dagliga mötena, dessa hinder kan prioriteras och systematiskt besegras av gruppen som helhet. Detta leder till att välstyrda Scrum-projekt kan uppnå Toyota-effekten, produktivitet fyra gånger högre och av tolv gånger bättre kvalitet än industristandardnivå[33].

2.1.4

Designsprint

När en grupp börjar på något helt nytt vill många utvecklare börja med att ägna tid åt att skissa och designa helheten så att alla strävar mot samma mål när den verkliga utvecklingen börjar. Ett sätt att lösa detta är köra kortare designsprintar i början av nya projekt, de fungerar i stort som vanliga sprintar. Den enda skillnaden är att de ofta är kortare. Liknelsen mot det vanliga arbetet gör att gruppen inte behöver lära sig ett nytt sätt att arbeta när designarbete utförs [23].

Det finns dock ett antal personer som förespråkar “Ren Scrum eller ingen Scrum”, de anser att om ändrar man något så tappar man poängen med metodiken. Designsprintar är egentligen ett brott mot Scrums principer om att inte designa i förväg då det kan hämma kreativiteten[28].

2.2

Distribuerad Scrum

Följsamma metoder är väldigt beroende av kommunikation ansikte mot

ansikte vilket blir dyrt om utvecklingen är utspridd över kontor med stora avstånd mellan[23], så företaget behöver anpassa processen till sin situation. Men det är långt från riskfritt, Sutherland m.fl[34] identifierar ett antal risker för företag som arbetar distribuerat, även distribuerad Scrum.

Strategisk Problem med att utnyttja alla tillgängliga resurser, de kan finnas på fel ställe vid fel tidpunkt.

Projekthantering Problem med att synkronisera arbetet mellan kontoren. Kommunikation Problem med att kommunicera effektivt.

Kulturell Kulturella skillnader mellan kulturer de olika kontoren befinner sig i. Teknisk Olika de facto-standarder på olika platser.

Säkerhet Problem med att hålla kommunikation över långa distanser säker från hot som t.ex. störning eller avlyssning.

Avstånden och uppdelningen medför en del problem i utvecklingen, men det finns etablerade metodiker för att lösa dem som Jeff Sutherland m.fl. har beskrivit[34]. Problemen är dock relativt små, Scrum kan hjälpa kontor som utvecklar

distribuerat att komma närmare varandra genom att de tvingas kommunicera mycket regelbundet med varandra jämfört med traditionella metodiker. Det finns en studie av Paasivara m.fl som visar att Scrum kan hjälpa företag att få tätare kontakt mellan kontor även om de ligger långt ifrån varandra[23]; de upptäckte att gruppmedlemmar kommunicerar betydligt mer en och en mellan kontoren när de haft kontakt via de dagliga mötena tidigare. För att minska risken för att de dagliga mötena drar ut på tiden och att missförstånd sker på grund av språk-förbistringar rekommenderar Sutherland m.fl. att gruppmedlemmarna svarar på de tre frågorna(se 2.1.3) via mail innan mötet.

Människor litar också mer på de som de har arbetat i samma lokaler som tidigare. Detta är ett tungt argument för att distribuerade företag bör etablera reserutiner som får gruppmedlemmar att resa mellan kontoren[23].

Det finns tre typer av distribuerad Scrum, i stort sett alla grupper som jobbar med Scrum över flera geografiskt isolerade kontor tillhör någon av dessa:

Isolerade Scrum-grupper Grupperna har knapphänt kommunikation mellan grupperna, en grupp kanske inte jobbar med Scrum alls.

Sammankopplade Scrum-grupper Grupperna har delade uppgifter men har regelbunden kommunikation.

Integrerade Scrum-grupper Grupperna delar på uppgifter och personal. Detta kan ses som en skala mellan två helt separata grupper och två delar av samma grupp. Integrerade Scrum-grupper kommer att behöva betydligt mer administration att hålla igång än Isolerade Scrum-grupper, men kommer troligen att ge betydligt högre produktivitet också[23].

2.3

Dokumentation, långa projekt och Scrum

Mjukvaruutveckling består av två stora delar, utveckling och underhåll, där utveck-ling ofta är en relativt kort tid medan underhållet kan sträcka sig över en betydligt längre period. Med underhåll menas arbetet med att fixa problem och lägga till extra funktionalitet i system som redan finns ute hos kunder. Under

utvecklingen av små projekt som bara pågår under en kortare period där alla utvecklare finns kvar i projektet är brist på dokumentation sällan ett problem men det kan bli stora problem när helt andra utvecklare ska underhålla systemet

2.3 Dokumentation, långa projekt och Scrum 15

senare. I de fall där det är olika utvecklare som jobbar med utveckling och under-håll behöver man för effektivt underunder-håll föra över information om hur systemet fungerar och var ändringar kan göras. Misslyckas detta kommer det slutligen att leda till att projektet misslyckas[26].

2.3.1

Dokumentation i traditionella metodiker

I traditionella metodiker ses dokumentation som den främsta informationskanalen, vilket innebär att mycket tid behöver läggas på att skriva och uppdatera olika typer av dokumentation för diverse ändamål. Det finns dock studier som visar på att utvecklare i praktiken är dåliga på att dokumentera och sällan känner att det är värt tiden det tar att uppdatera vissa typer av dokument[26]. Följden blir att dokument inte skrivs och uppdateras som de ska och blir gamla, oanvändbara och att tiden som lagts ner på dem dittills i vissa fall blir helt bortkastad. Om dokumenten å andra sidan hålls uppdaterade växer de och kan innehålla allt man behöver veta som ny, men tar väldigt lång tid att läsa genom.

Det finns studier som visar på brister med att använda dokumentation som medium för att behålla och distribuera information: om den är dåligt utförd kan det sänka kvalitet och produktivitet[14], men om den är väl utförd kan den å andra sidan höja både produktivitet och kvalitet[14].

2.3.2

Dokumentation i Scrum

Att Scrum är följsam innebär att det inte läggs fokus på dokumentation utan att mer tyngd läggs på att kunna följa skiftande krav från kunden. På grund av processens inneboende föränderlighet är det ingen mening med att göra långt-gående detaljerade planer[29]. Då kunden ofta ändrar sig eller kanske inte vet vad som är målet är det sällan någon större poäng med att lägga tid på att

dokumentera något som kan fungera väldigt annorlunda när det är dags för slut-giltig leverans. Detta bidrar till att dokumentationen medvetet blir bristfällig, och under ett Scrum-projekt är källkod och kommentarer den enda dokumentation som produceras som en bieffekt av processen. Istället rekommenderas kommunikation och samarbete mellan medarbetare för att hålla information i gruppen. Annan dokumentation kan skrivas vid behov, t.ex. små anteckningslappar, för att underlätta kommunikationen men det ingår inte som en nödvändig del av processens artefakter[31].

Det finns dock studier som visar på att underhåll av Scrum-projekt kan fungera trots bristande dokumentation, det finns alternativa informationskanaler som fungerar lika bra eller ännu bättre: ett företag, benämns företag A, har utvecklat och underhållit med Scrum i 20 år[26]. Huruvida företaget lyckas hänger dock på några faktorer:

Levande dokumentation Levande dokumentation innebär att informationen finns bland personalen, all kunskap bör finnas hos minst två personer så att den finns kvar om någon slutar. Företag A har som tradition att en anställd ägnar dagarna innan denne slutar åt att tala om för de andra vad hon eller

han jobbar på nu och beskriva lämpliga sätt att fortsätta[26], och det fungerar väldigt bra för dem.

Det finns studier som visar på att större delar av kunskap relaterad till mjukvaruututveckling finns i personalens minne och inte i dokument[25]. Detta gäller även hos företag som jobbar med traditionell metodik vilket ger stöd åt metodiker som tar det faktumet lite längre och formaliserar det. Intern kommunikation Då all kommunikation sker bland personalen är det

viktigt med välfungerande informationskanaler inom gruppen för att informationen ska sprida sig.

Låg personalomsättning Låg personalomsättning är en viktig del av att behålla information om folk försvinner innan de hinner föra vidare vad de vet förlorar företaget information. Får detta pågå en längre period blir det inte längre hållbart och projektet riskerar att få allvarliga problem, särskilt när utvecklingen är klar och underhållet ska ta vid.

Välkommenterad kod Välkommenterad kod är en form av dokumentation som effektivt kan föra vidare specifik information om hur systemet fungerar. Välkommenterad kod strävar många utvecklingsföretag efter men i många fall brister rutinerna av olika anledningar, det kan vara bristande intresse eller tid från utvecklaren, samtidigt kan det vara motiverande för

utvecklarna om de vet att kommentarerna är den enda dokumentation de behöver skriva.

Om ett företag lyckas hålla dessa faktorer på rätt nivå finns det en chans att företaget klarar sig och lyckas[26]. Enskilda är tre av faktorerna åtråvärda i sig, men att formellt satsa på enbart levande dokumentation kan möjligtvis bli ganska knepigt för vissa chefer.

Det är dock inte helt enkelt, det finns flera risker kopplade till att kunskap bara finns i personalens huvuden[14], några av de större är

• Man dokumenterar inte bara systemet, man dokumenterar processen. Detta är enligt studien en viktig del i arbetet med att förbättra processen enligt principen att om man inte vet vad man gör inte kan göra något bättre. • Muntlig kommunikation tar tid och man måste börja med att hitta rätt

person att fråga. Det kräver också tid av två personer istället för en person. • Flera företag fann att arkitekturen blir lidande när utvecklare gör ändringar

på fel ställen då de inte är så välinformerade om.

Generellt visade det sig dock i studien att samma punkt aldrig orsakade problem på samtliga företag, det var alltid något eller några som lyckades.

Vissa former av dokumentation är inte en del av processen utan en del av resultatet, t.ex. användarmanualer. En del mjukvaruföretag har särskild personal för detta, teknisk informatör. Baptista anser att de under en sprint bör ges mer arbete än de kan klara av, och sedan själva får prioritera[2]. Detta går delvis emot Scrums principer, det ska vara produktägaren och inte gruppmedlemmarna

2.3 Dokumentation, långa projekt och Scrum 17

som prioriterar(se 2.1.2) men det ska finnas mer arbete än de kan klara av. Dock har vissa uppgifter en ideal timing, man bör inte dokumentera något förrän det är färdigt för släpp till kund, och sådan prioritering bör troligen lämnas till författaren som har detaljkunskapen.

I en del fall behöver man dokumentation. Om en grupp ska utveckla kärnan och en annan grupp en modul så vill gruppen som utvecklar modulen ha ett tydligt gränssnitt till kärnan så att man slipper ändra i sin kod varje gång kärngruppen ändrar något. Detta blir svårt i följsamma metodiker, och om man börjar med att spika gränssnittet kan det hindra kärngruppen från att utveckla arkitekturen till sin fulla potential. Schwaber föreslår att man synkroniserar sprintarna som lösning så att båda sidor av gränssnittet arbetar med det samtidigt. En annan lösning är att man har en särskild grupp som består av folk från andra grupper vars enda uppgift är att se till att det blir så få problem vid integrering som möjligt[29].

Det blir ett flertal problem om man ska blanda följsamma och traditionella metodiker i samma organisation, Boehm m.fl. beskriver dessa och lösningar[3]. Det blir särskilt problem när det gäller dokumentation; följsamma metodiker har sällan dokumentation som en resulterande produkt och traditionella metodiker behöver ofta ett flertal dokument för utbildning eller underhåll[26].

Ibland kör företag enskilda Scrum-projekt medan cheferna arbetar enligt traditionella metodiker och förväntar sig traditionell rapportering, t.ex. Gantt-scheman. Då Scrum inte planerar uppgifter längre än en sprint från blir det svårt att säga exakt hur långt man har kommit på vägen mot målet, vissa uppgifter kanske produktägaren inte tycker är värda att implementera när det kommer till kritan. En lösning som gjorts tidigare[28] är att konvertera Scrum-dokumentationen till traditionella metodiker, implementationslistan kan ganska enkelt göras om till Gantt-scheman.

Kapitel 3

Nuvarande process

I det här kapitlet beskrivs Medius variant av Scrum, vilka typer av personal som finns på Medius och vilka dokument de använder samt vilka verktyg som används för att underlätta arbetet.

3.1

Scrum på Medius

Medius har anpassat Scrum lite efter egna behov[18]. Istället för en produktägare har de ett produktråd som sköter samma uppgifter: hanterar implementations-listan, prioriterar PBI:er och annat. När det bestämts vad som ska ingå i sprinten samlas gruppen och delar upp arbetet mellan sig, då märker man också ifall man planerat in för mycket funktionalitet i en sprint och kan kapa funktionalitet redan vid start. Gruppen som utvecklar MediusFlow varierar lite men ligger mellan 8-10 personer, det vill säga i det övre spannet av hur stora grupper får vara. Medius har ett praktiskt hinder i att gruppen är utspridd mellan Linköping, Krakow och Stockholm, så det går inte att ha dagsmötena ansikte mot ansikte. Detta har de löst genom att istället ha morgonmötena över Skype. Tidigare har de tummat på tidsgränsen, de brukade landa på runt 20-25 minuter vilket är över gränsen för Scrum. Detta berodde på att Scrum-mästaren inte styrde mötet tillräckligt och folk kom igång med diskussioner under själva mötet. Detta håller dock på att åtgärdas och nu ligger mötestiden under 15 minuters-gränsen, .

Tidigare släpptes varje sprint till kund men detta höll inte i längden på grund av praktiska begränsningar - konsulter och support tyckte att det blev för många olika versioner ute hos kund. Detta gjorde att det gick åt mycket tid när varje bugg behövde fixas i så många olika versioner. Problematiken fick följden att de gick över till att bara släppa var tredje sprint till kund, så numera gör man en s.k. baseline av den funktionaliteten som ingår när var tredje sprint är avklarad.

En baseline är en version som släpps till nya kunder, de får den senaste base-linen. När var tredje sprint är avklarad genomgår applikationens delar mer utförliga enhets- och integrationstester. När de klarats av körs systemtester på hela

applikationen. När applikationen slutför alla tester med tillfredställande resultat 19

anses den klar och släpps till kunder. Gamla kunder kan få buggfixar i Hotfix-versioner om de inte kan vänta upp till tre månader på buggfixar.

Medius är utspritt på ett flertal kontor men utveckling sker på tre kontor som ligger i Linköping, Krakow och Stockholm. Medius har anpassat sig till avståndet genom att dels ha de dagliga morgonmötena via Skype och dels ha en del personal som reser mellan kontoren. Detta gick bra tidigare när det var kontor i Linköping och Stockholm, men i och med att kontoret i Krakow etablerats finns risken att kontoret hamnar lite utanför i resandet.

3.2

Personal och dokument

Jag har kartlagt vilka dokument som skrivs och uppdateras av vem och när det görs, samt vem som läser dem och när de läser dem. Denna del av arbetet genom-fördes för att se vilka typer av kopplingar som den nya processen behöver kunna stödja.

Enligt anställda på Medius[18] produceras och uppdateras i dagsläget ett antal dokument av olika personer i skilda avdelningar.

• Utvecklare • Säljare • Konsulter • Leverans • Support

3.2.1

Utvecklare

Utvecklarna producerar ett antal dokument relaterade till PBI:er, buggar och annat.

Designspecifikation En beskrivning av hur en PBI ska implementeras.

Testspecifikation En beskrivning av hur Medius ska kontrollera att PBI:n har implementerats korrekt.

Lösningsförslag Ett utkast till hur funktionaliteten ska designas och

implementeras. Innehåller ofta utkast till skärmdumpar, hur lösnigen bör se ut för användaren.

Kravspecifikation En specifik lista över konkreta krav som ska nås för att PBI:n ska anses klar. Det är inget krav på att dokumentet ska finnas, i många fall läggs innehållet istället in i lösningsförslaget, men för stora PBI:er skrivs det som komplement till lösningsförslaget. Kravspecifikationen skrivs ofta i samråd med personen som hade förslaget från början.

Användarhandledning En guide för hur produkten bör användas, en form av manual som ofta är kortare och bara omfattar en viss del av produkten.

3.2 Personal och dokument 21

Figur 3.1. Ett enkelt flödesschema för när ett förslag har accepterats av produktrådet

Konfigurationshandledning En guide över de olika inställningarna man kan göra i applikationen.

Buggöversikt En översikt över buggar som ska rättas i nuvarande sprint och i vilka versioner de ska rättas. Då kunder kör en mängd olika versioner är det ibland ett antal versioner som en bugg måste fixas i, förutom den senaste som ska inkludera alla buggfixar.

Produktdefinition En komplett beskrivning av hela applikationen och vad alla delar klarar av.

Det finns även två dokument som skrivs och uppdateras av chefsutvecklarna och används av vanliga utvecklare under det dagliga arbetet.

Utveckingsriktlinjer Beskriver hur arbetet med att utveckla ny funktionalitet eller rättning av buggar ska ske.

Programmeringsriktlinjer Riktlinjer för hur kod ska se ut i applikationen. När en ny PBI skapas ska fyra dokument skrivas: designspecifikation, test-specifikation, lösningsförslag och kravspecifikation. Dessa behöver uppdateras när PBI:n är slutförd men efter det uppdateras de sällan eller aldrig. Då funktionalitet inte ändras förrän en annan PBI innehåller en förändring anser jag inte att detta är ett problem.

En användarhandledning skrivs alltid medan en konfigurationshandledning skrivs först när den anses behövas. Tidigare uppdaterades dokument först när de skulle skickas ut vilket innebär mycket arbete och medförde risken att ny funktionalitet inte blir dokumenterad. Arbete pågår dock med att strama åt dokumentations-processen; användarguider ska uppdateras kontinuerligt.

3.2.2

Säljare

Säljarna använder ganska naturligt en annan samling dokument än utvecklarna. På grund av att man släpper en ny version var tredje månad och den genomsnittliga tiden från kontakt till kontrakt för en kund är runt ett år så kan inte säljarna använda versionsspecifik dokumentation utan måste arbeta i mer generella termer. Säljare arbetar med följande dokument:

• Offerter • Egna prislistor • Presentationer • Partners prislistor • Produktblad

Dessa dokument är ofta “andrahandsdokument”, någon som har använt mjuk-varan istället för någon som skapat mjukmjuk-varan skriver dem. Då de går ut till potentiella kunder är det väldigt viktigt att de är uppdaterade, men då de ofta har skrivits av säljare bör säljare uppdatera dem.

Många av dessa dokument behöver inte uppdateras för varje ny PBI utan kan uppdateras först när det skett betydande förändringar i applikationen. Vissa av dokumenten går på helt andra uppdateringscykler, som prislistor, offerter och liknande ekonomiska dokument.

3.2.3

Konsulter

Konsulterna är den tredje stora gruppen på Medius och de producerar och använder följande dokument.

Manualer

Användarhandledningar Konfigurationshandledningar

Tekniska riktlinjer Dokument som beskriver diverse olika tekniska rutiner, till exempel hur man utför installationer eller hur filer är namngivna.

Aktiveringsdokument Dokument som beskriver hur en viss del av applikationen kan aktiveras, ändringar i databasen, etc.

3.3 Externa dokument 23

Teknikkonsulter

Teknikkonsulterna utför installationer, konfigurerar applikationen och hanterar liknande uppgifter som rör applikationens funktionalitet och prestanda ute hos kund. De integrerar applikationen med existerande system eller tidigare versioner av applikationen.

Teknikkonsulterna använder främst användarguider, konfigurationsguider och tekniska riktlinjer när de arbetar.

Applikationskonsulter

Applikationskonsulternas har flera roller. Dels lär de ut hur systemen bör användas av kunden. När ett system ska sättas upp ute hos kunden kommer den tillsammans med en applikationskonsult fram till hur det bör se ut. Sedan utför en teknikkonsult installationen och när det är klart anpassar applikationskonsulten den till kundens önskemål. När allt är klart håller de också i utbildningar och hjälper kunden att komma igång med sitt arbete. Då de har mycket kundkontakt faller det på dem att också föra kundens talan inom Medius samt vara Medius ansikte mot kunden.

Applikationskonsulterna använder främst manualer, användarguider och konfigurationsguider när de arbetar.

3.2.4

Leverans

Leverans tar över när teknikkonsulterna är klara med att sätta upp miljön ute hos kund. Teknikkonsulterna sätter upp en testvariant och när kunden ser att allt fungerar tillfredställande kopieras denna varpå miljön rensas från testdata och liknande, sedan är den färdig att sättas i drift av kunden och applikations-konsulterna kan ta över med att utbilda kunden i hur den bör användas.

3.2.5

Support

Support arbetar med att hjälpa kunden vid problem den inte klarar av på egen hand. De håller ingen regelrätt utbildning, det ligger på applikationskonsulterna, utan ger hjälp vid specifika problem som kunden kan stöta på under sitt

kontinuerliga arbete med applikationen. En viktig del av deras arbete är att bestämma huruvida ett problem beror på att kunden gjort fel eller om det är ett fel i programmet som måste åtgärdas.

Supporten använder ingen dokumentation när de löser problem, de kollar bara på programkoden i applikationen.

3.3

Externa dokument

Dokument utanför Medius går till två typer av företag: kunder och partners. Huvudansvaret för att dokumenten kommer till rätt personer ligger på leverans-organisationen.

3.3.1

Kunder

Kunder vill ha många typer av dokumentation för att i så stor utsträckning som möjligt hantera driften av systemet själva. Vissa kunder skriver med dokument-ation i kravlistor som inkluderas i avtalen, andra begär den allteftersom den behövs. Numera finns dokumentationen direkt i applikationen vilket gör att detta till viss del hamnar på utvecklarnas bord.

3.3.2

Partners

Partners behöver dokumentation för att kunna marknadsföra och sälja systemet. I och med Medius internationella satsning behöver fler och fler dokument finnas uppdaterade på minst två språk: svenska och engelska.

3.4

Dokumenttyper

Det går att klassa dokument efter hur ofta de uppdateras, hur små ändringar i applikationen som behövs innan dokumentet kan anses gammalt och behöver revideras. Jag har identifierat fyra klasser: PBI-specifika, känsliga, måttligt känsliga, okänsliga.

PBI-specifika Dokument som bara rör en specifik PBI och egentligen inte hela produkten. Detta gör att de inte behövs mer när PBI:n är slutförd, utan kan lämnas i arkivet.

Känsliga Dokument som är relativt känsliga, de speglar ganska detaljerad funktionalitet och det är viktigt att de hålls uppdaterade kontinuerligt. Tar det för lång tid mellan uppdateringarna närmar man sig gränsen för när det är enklare att börja om med dokumentet från början istället för att undersöka vad som ändrats.

Måttligt känsliga Dokument som inte reflekterar applikationen på en särskilt detaljerad nivå. Vid större förändringar bör de uppdateras men det kan gå en tid mellan uppdateringarna utan att det är direkt dåligt.

Okänsliga Dokument som är till stor del eller helt okänsliga för funktionalitet. De innehåller få eller inga detaljer om produkten och kan ha helt andra uppdateringsintervall.

Känsligheten är direkt kopplad till när ett dokument bör uppdateras. Känsliga dokument bör ofta uppdateras när en relevant PBI är avklarad, medan ett produktblad kanske bara behöver uppdateras för varje baseline eller ännu mer sällan medan till exempel offerter har helt andra uppdateringscykler och klassas som frikopplade.

PBI-specifika:

Designspecifikationer Testspecifikationer

3.5 Nuvarande verktyg 25 Lösningsförslag Kravspecifikationer Aktiveringsdokument Känsliga: Användarhandledningar Konfigurationshandledningar Buggöversikter Manualer Använderhandledningar Konfigurationshandledningar Tekniska riktlinjer Produktdefinitioner Måttligt känsliga: Produktblad Presentationer Frikopplade: Offerter Egna prislistor Partners prislistor Programmeringsriktlinjer Utveckingsriktlinjer

3.5

Nuvarande verktyg

3.5.1

Team Foundation Server

Team Foundation Server[35] (TFS) är Microsofts lösning för utvecklingsgrupper, det är efterföljaren till Visual Sourcesafe, Microsofts tidigare verktyg för ungefär samma ändamål. Det är gjort för att täcka upp alla aspekter av utvecklingen för ett mjukvaruföretag. TFS innehåller bland annat1

• Versionshantering • Bugghantering • Funktionalitetshantering • Webbåtkomst • Automatiserade byggprocesser • Automatiserade tester • Rapportgenerering

1_{För mer detaljerad beskrivning se http://msdn.microsoft.com/en-us/library/ms242904.}

TFS är fokuserat runt konceptet arbetsuppgift. En arbetsuppgift kan vara en bugg som ska fixas, en ny funktion som ska implementeras eller något annat som ska utföras; en arbetsuppgift är en PBI eller en bugg.

I Team System, Visual Studio Team Explorer och Team Foundation

Server, finns det två typer av projekt. Arbetsprojekt och gruppprojekt; arbets-projekt innehåller alla kodfiler och liknande som produceras under arbetets gång medan gruppprojekten innehåller information om vad som ska göras, PBI:er och liknande.

Dokumentation för en PBI

Varje PBI ska ha ha länkar till ett antal dokument: designspecifikation, test-specifikation, lösningsförslag och kravspecifikation. För mer detaljerad

information om dokumenten, se avsnitt 3.2.1. Tidigare var det dock långt från alla PBI:er som hade alla dokument kopplade till sig, men det har skett en uppstramn-ing, nu är ett lösningsförslag obligatoriskt innan PBI:n antas för utvärdering över huvud taget, och resterande dokument ska också skrivas.

Det finns även stöd för att ha länkar till andra dokument, arbetsuppgifter, noteringar eller annat som kan vara relevant. Varje PBI delas upp i ett antal SBI:er och i TFS finns det kopplingar åt båda håll mellan varje SBI och dess PBI-förälder.

Dokumentation för en bugg

Buggar har som regel ingen dokumentation kopplad till sig men GUI-relaterade buggar kan ha skärmdumpar som visar hur det ser ut när användaren råkar ut för buggen. De har även en koppling till en eller flera SBI:er som motsvarar rättandet av buggen.

3.5.2

Visual Studio 2008

Idag använder Medius Visual Studio 2008[37] som är en integrerad utvecklingsmiljö, det vill säga en helhetslösning för utvecklare. Det ingår texteditor med funktion-alitet för att underlätta skrivande av programkod i specifika programmeringsspråk. Visual Studio 2008 Team System är en version av Visual Studio som innehåller funktionalitet för att underlätta arbetet för flera utvecklare att arbeta med samma projekt, till exempel har det inbyggt stöd för att koppla projekt mot versions-hantering eller hanterare. Det finns stöd för att koppla ihop projekt med en TFS, då får man integrerat stöd för att hantera kopplingar mellan programkod och SBI och därigenom även till PBI:er.

Visual Studio 2008 är inriktat mot utveckling på .NET-plattformen men stöder även utveckling mot maskinkod om man skriver i C++.

3.5.3

.NET-plattformen

3.5 Nuvarande verktyg 27

Lågnivåspråk Språk som ligger väldigt nära maskinkod, här finns i stort sett bara olika typer av Assembler, även om vissa skulle lägga ren C här. Program-meraren har stor kontroll över vad som händer men behöver göra mycket själv. Det går att optimera kod väldigt hårt om man vet vad man gör, men det krävs ofta lång erfarenhet innan man kan börja med mer avancerade saker.

Mellannivåspråk Språk som ligger lite högre upp: C++, Delphi och liknande språk som kompileras till maskinkod. Lite mindre kontroll över vad som händer än i lågnivåspråk men det går fortare att utveckla hela program. Språk på den här nivån har ofta möjlighet att lägga in avsnitt med låg-nivåspråk. Inom riktigt prestandakrävande områden som spel där man vill pressa hårdvaran så mycket man kan är mellannivåspråk i överväldigande majoritet.

Högnivåspråk Språk som ligger väldigt högt upp i abstraktionsnivå. Språket gör mycket automatiskt vilket gör att utveckling går fort men som utvecklare har man i vanliga fall inte så mycket kontroll över vad som händer. Högnivåspråk är ofta enklare att komma igång med för att det inte krävs så mycket kod innan man ser ganska stora resultat.

Många högnivåspråk körs i virtuella maskiner som tolkar bytekoden och utför instruktionerna vilket ger plattformsoberoende men också innebär långsam-mare exekvering. På senare år har det dock kommit två varianter för att komma runt detta tapp i hastighet.

• JIT(Just In Time)-kompilering som innebär att bytekoden kompileras till maskinkod när programmet körs. Det tar lite längre tid när koden körs första gången men programmet som levereras som bytekod är plattformsoberoende.

• Kompilering till maskinkod. Vissa kompilatorer för vissa språk kan kompilera direkt till maskinkod istället för bytekod. Man tappar ingen hastighet men programmet blir inte längre plattformsoberoende. .NET-plattformen är ett samlingsnamn för en rad olika tekniker som till-sammans gör det möjligt att skriva i flera olika språk, kompilera ner till samma format och sedan köra på olika plattformar eller operativsystem.

Högst upp, se figur 3.2, finns naturligt nog de olika språk programmeraren kan använda.

Under dem finns Common Language Specification[7] (CLS), en specifikation som Microsoft och skrivit som anger vilka anrop som måste finnas på varje objekt för att det ska kunna användas i valfritt .NET-språk. CLS innehåller en samling regler som är ett subset av Common Type System.

Common Type System[8] (CTS) beskriver hur typer deklareras, definieras och hanteras i miljön. Där definieras även ett antal vanliga typer som har

representationer i de olika språken. Till exempel finns System.Int32 i CTS vilket i C#_{representeras av datatypen “int” medan den i VB.Net representeras av}

Figur 3.2. Delarna av .NET ramverket[21], högre upp är närmare användaren

.NET Framework Class library[11] (FCL) är en samling klasser som erbjuder färdig funktionalitet. Det hjälper utvecklaren att snabbare få sin mjukvara färdig genom att använda dessa klasser istället för att skriva sina egna från grunden. De ger utvecklaren tillgång till bland annat:

• GUI • Nätverk • Filhantering

Under FCL ligger interna bibliotek för GUI, konsol, databaskopplingar, webb-formulär och annat.

Allt detta körs av Common Language Runtime[6] (CLR) som innehåller kom-pilator, skräphantering, säkerhet och annat. Kompilatorn är till för att kompilera .NET-applikationer från bytekod till maskinkod när de startas. Då kan de köras av processorn och behöver inte översättas av en virtuell maskin och tappa prestanda. Hela den här kedjan är Microsofts version av Common Language Infrastructure[5] (CLI). Den har blivit en officiell standard under ECMA och går där under namnet “ECMA-335”. CLI definierar varje steg från programspråk till exekvering och om ett språk är CLI-kompatibelt innebär det att du kan ta bytekoden, i Microsofts fall kallas den Microsoft Intermediary Language eller MSIL, och köra i valfri CLI-kompatibel miljö.

3.6 Utvärdering 29

3.6

Utvärdering

Grunden för denna utvärdering har varit intervjuer med anställda på Medius samt personliga reflektioner. I de fall där det är jag som anser något skriver jag ut det, annars är det baserat på intervjuer.

Det finns ett antal brister när det gäller dokumentation av vissa PBI:er. De har inte de dokument kopplade till sig som de ska ha, och i vissa fall är innehållet i dokumenten väldigt begränsat. Författaren har bara skrivit en rad eller två för att skriva något, inte lagt ner tid på att skriva ett ordentligt lösningsförslag. Ett relaterat problem är att vissa dokument kan vara långa men väldigt svåra att sätta sig in i då de förutsätter stor kunskap om koden, som inte alla har. Denna åsikt kom från en nyanställd så detta löser sig troligen med tiden.

När utvecklingen med en PBI är avslutad uppdateras dokumentationen bara i vissa fall, i många andra lämnas dokumentationen som den är. I de PBI-specifika dokumenten är detta sällan ett problem men när det gäller produktdefinition, användarhandböcker och andra dokument som är aktiva under en längre tid blir detta ett problem.

Några dokument ska skrivas till varje PBI: testning, design, lösningsförslag etc. Alla dessa dokument går emot den dokumentlösa grundtanken med Scrum vilket Medius är medvetna om, men har valt att kompromissa.

Konsulterna har i dagsläget ingen ordentlig kanal för informationsutbyte mellan sig för att förmedla hur långt ett projekt har kommit. I dagsläget har de en tillfällig lösning som inte ger någon överblick eller vettigt perspektiv över detaljer.

Uppdateringar av dokument prioriteras i en del fall ned, i enstaka fall glöms de även bort eller missas helt, mail blir liggande i inkorgar eller arkiveras bort.

Det finns några möjliga orsaker till detta. Medius har växt i väldigt snabb takt under flera års tid och fortsätter att växa i samma takt medan dokumenthantering och arbetsprocesser inte verkar ha hängt med i samma takt. Interna processer har ofta en tendens att bli lidande i vanliga fall, företag fokuserar naturligt på de delar som får in pengarna, och jag tror att detta fenomen blir förstorat under kraftig uppgång. Det faktum att Medius utökat från ett kontor till flera kontor i både Sverige och utomlands och de kommunikationsproblem detta medför bidrar troligen också.

Medius dokumenthantering och -uppdatering har tidigare varit bristfällig och har fortfarande ett antal brister. De är dock medvetna om många av problemen och jobbar för att åtgärda dem. Om min nya process kan underlätta detta arbete anser jag att arbetet har lyckats.

Kapitel 4

Ny process

Den nya processen har utvecklats för att uppnå funktionalitetsriktlinjerna som finns i Appendix A. Kapitlet är uppdelat i fyra Adelar, först kommer beskrivningar av hur hantering av uppdateringar respektive genereringar kan ske, detta följs av ett avsnitt som beskriver tekniken bakom och slutligen ett avsnitt om hur detta skulle kunna implementeras.

Processen består av två huvuddelar. • Hantering av uppdateringar av dokument • Generering av dokument från dokumentdelar

4.1

Hantering av uppdateringar av dokument

Processen ska klara av att hantera uppdateringar av existerande dokument. När en utvecklare checkar in kod ska rätt person(er) uppmärksammas på att rätt delar av rätt dokument bör uppdateras.

Figur 4.1. En översiktsbild av dokumentuppdatering med den nya processen

4.1.1

Scenarion

Fyra scenarion beskriver hur arbete enligt den nya processen skulle kunna fungera. Det finns ett antal roller i dessa scenarion.

• Programmeraren Per

• Programmeraren Pernilla

• Marknadsförare Markus

• Chef Charlotte

Scenario 1 - Direkt till samma utvecklare

Figur 4.2. Scenario 1

Per har precis blivit klar med en PBI och ska checka in filerna relaterade till den. När han checkat in kommer det upp en dialogruta som talar om att kapitel 2, avsnitt 3 av manualen och kapitel 4, avsnitt 5 och 7 av produktdefinitionen behöver uppdateras. Modulen hämtar hem och öppnar dokumenten så att Per kan redigera dem direkt. När modulen hämtat hem och öppnat alla väntar den tills alla fönster har stängts ned igen och då skickar den tillbaka alla till TFS:en.

4.1 Hantering av uppdateringar av dokument 33

Scenario 2 - Till annan utvecklare

Figur 4.3. Scenario 2

Pernilla har blivit klar med arbetet med två PBI:er men har fått ett viktigt uppdrag vid sidan av som måste bli klart innan hon kan uppdatera dokumenten till PBI:erna. Hon hör med Per som har det lite lugnare, han blev ju precis klar med sin PBI och han säger att han kan ta på sig att uppdatera dem så att han har hyfsad koll på vad PBI:erna innebar. När hon checkar in koden ber hon servern att lägga dem på Per istället med en notering om att de egentligen är Pernillas.

Scenario 3 - Till säljare

Pernillas ena PBI var en markant skillnad i gränssnittet, tillräckligt stor för att produktbladet behöver uppdateras med nya skärmbilder och lite ny text. Då produktbladet ligger på säljare läggs avsnitt 4 av produktbladet till på Markus lista, och när alla listor körs genom vid midnatt går ett mail ut till Markus om att avsnitt 4 av produktbladet behöver uppdateras (skulle även kunna gå till alla säljare så att de får dela upp arbetet mellan sig). När uppdateringen är klar går de in på en webbsida och markerar att uppdateringen är klar, görs inte detta inom ett antal dagar skickar systemet ut en påminnelse.

Figur 4.5. Scenario 4

Scenario 4 - Chef

Charlotte är chef över en samling medarbetare och vill ha lite översikt över hur mycket dokumentationsarbete de lämnar efter sig. Då kan hon gå in på webb-servicen och se vilka dokument som ska uppdateras av vilka personer, vilka som redan är uppdaterade och liknande information. Om hon ser att en anställd sackar efter med sina dokumentuppdateringar kan hon ta ett samtal med personen innan det spårar ur helt.

4.2

Generering av dokument från delar

Det ska gå att generera dokument från delar. Man väljer vilket dokument man vill skapa så hämtas rätt delar och dessa slås samman till ett dokument som läggs upp på Medius Sharepoint-installation.

Figur 4.6. En översiktsbild av dokumentgenereringen med nya processen

4.2.1

Scenarion

Nya roller som ingår i dessa scenarion

4.2 Generering av dokument från delar 35

Scenario 5 - Lägga till PBI

Figur 4.7. Scenario 5

Per ska lägga till en ny PBI i implementationslistan. Då behöver han koppla ett antal dokument till denna: dokumentdel för versionsinformation, dokumentdel för användarhandledning etc. Dessa läggs också till som uppdateringsdokument; när PBI:n är klar ska Per uppdatera dem med den nya funktionaliteten.

Scenario 6 - Generera dokument

Figur 4.8. Scenario 6

Charlotte vill generera versionsinformation för den nya versionen som ska släppas till kund. Då väljer hon Versionsinformation som dokumenttyp och väljer de

arbetsuppgifter som bygger upp den releasen. Webbservicen går igenom varje arbetsuppgift och hämtar hem de dokumentdelar som är kopplade till arbets-uppgiften och bygger upp rätt dokumenttyp. Dessa delar slås sedan ihop till ett gemensamt dokument som läggs upp på Sharepointen.

4.3

Implementering

Processen består av tre huvuddelar: • Visual Studio

• Team Foundation Server

• Webbservice, agerar mellanhand mellan utvecklare, TFS och personer som ska uppdatera dokument

För att detta ska kunna fungera i praktiken behöver ett antal verktyg tas fram eller modifieras och det behövs ett antal kopplingar mellan olika personer och artefakter, 4.10. Olika dokumenttyper ska ändras av olika roller och man behöver därför definiera vilka dokument som ska ändras av vilka, se figur 4.9.

De två huvuddelarna av processen, uppdatering och generering, arbetar lite olika:

Figur 4.9. Kopplingar för dokumentuppdatering i nya processen

Figur 4.10. Kopplingar för dokumentgenerering i nya processen

4.3.1

Filformat

I mina exempel och undersökningar har jag fokuserat på Microsoft Word 2007(.docx) då det är formatet som används för dokument på Medius, men det ska finnas möj-lighet att senare kunna lägga till stöd för andra filformat.

4.3 Implementering 37

4.3.2

Dokumentlagringsmetoder

På något sätt behöver man lösa problemet med att bara visa upp rätt delar av existerande dokumentet för användaren. Det finns ett antal vägar att göra detta.

Jag rekommenderar att man implementerar en funktion som varje natt går igenom alla länkar och skickar de som inte stämmer till webbservicen, som bör in-nehålla funktionalitet för att användare ska kunna rätta till de felaktiga länkarna. Hur man identifierar en dokumentdel

Alla metoder där man sparar hela dokumentet ger ett problem, hur man ident-ifierar en del av ett dokument. Det finns två enkla sätt:

Rubrikens text Man sparar vad rubriken heter, “Rubrik 3 har texten

’Metodbeskrivning’ ” och förutsätter att det bara finns en rubrik med det namnet i dokumentet. Den här metoden klarar inte att man rättar stavning i eller döper om rubriker.

Rubrikens placering Man sparar var i dokumentet rubriken finns, “Rubrik 3 finns efter tecken 1743”. Metoden klarar inte av att man ändrar antalet tecken innan rubriken; lägger man till eller tar bort en enda bokstav i hela dokumentet före delen stämmer inte antalet längre.

Båda dessa får problem om dokumentet ändras efter att länken skapats. På grund av dessa brister föreslår jag en kombination av dessa metoder.

Man sparar var i dokumentet rubriken finns och vad den har för text. När det är dags att undersöka om länken stämmer kollar man om rubriken finns där och att texten stämmer, gör den inte det går man till närmaste rubrik som skiljer sig så lite som möjligt från den lagrade texten. Det blir en del merarbete men kommer förhoppningsvis att kunna klara av många små ändringar utan manuellt arbete. Användare bör bekräfta de nya kopplingarna, i de fall det går att hitta förslag på troliga nya kopplingar kan systemet förhoppningsvis spara mycket tid.

Dela lokalt

Man kan hämta hem hela dokumentet från servern, dela upp det genom mjukvara och visa upp temporära dokument. När användaren stängt ner dessa kopieras innehållet tillbaka till originaldokumentet som sedan skickas tillbaka till servern. Jag har gjort en kort undersökning och API:t för att styra Microsoft Word 2007 verkar kompetent nog för detta. Det finns dock problem: kopierandet fram och tillbaka kan bli svårt; stilmallar, bilder och liknande saker som är mer avancerade än vanlig text kan skapa problem.

Dela på server

Man kan sköta delningen av dokument på servern och bara hämta hem rätt delar av dokumentet. När användaren är klar skickar verktyget sonika tillbaka de modifierade delarna, och dokumentet slås ihop igen på servern. En fördel med