Person A påpekade något viktigt jag hade missat helt, en plan för hur processen ska införas i arbetet. Detta är onekligen en ganska stor sak för att processen ska gå att implementera i verkligheten, så det var synd att punkten missades.
Införandet kan innebära ett antal problem, kopplingar till alla de PBI:er som arbetas med idag behöver skapas och ett antal andra punkter vilket sammanlagt troligen kommer vara ganska mycket arbete. Jag tror att ett gradvis införande är rätt väg att gå, av samma anledning som att de inte vill skriva om hela systemet trots att det finns gamla brister och gamla tekniker används. Att göra allt i ett svep tar för mycket tid, men om alla gör lite då och då sprids kostnaden ut över en längre tid och blir mer acceptabel.
Det behövs ett nytt grupprojekt anpassat för den nya processen, och alla arbetsprojekt behöver kopplas om för att gå mot den istället. Om varje PBI man arbetar med flyttas över vid behov tror jag att de flesta relevanta PBI:er flyttas över inom en till tre månader, jag tror att de flesta PBI:er som kommer att implementeras väljs inom 3 sprintar. Men det kommer troligen att ta runt ett år innan personalen kan sluta kolla i det gamla grupprojektet efter uppgifter, då tror jag . Arbetet under införandet kommer att skötas mot två olika grupprojekt vilket kan innebära en del problem, uppgifter glöms bort eller faller mellan stolarna för att de ligger i det andra gruppprojektet så det kräver extra kontroll så att man vet att alla gör rätt saker.
En stor del av införandet är, som person E poängterade, personalutbildning. Alla behöver veta vad som behövs för en ny PBI, hur man genererar dokument från delar och många andra liknande uppgifter som alla behöver utföra innan de kan arbeta med den nya procesen i full fart. Detta kommer att ta tid att planera, genomföra samt följa upp, tid som hade kunnat läggas på produkten. Det här hänger ihop med tydligheten som nämns i avsnitt 6.1.3.
6.4
Övriga funderingar
6.4.1
Klassiska problem
Vissa problem är svåra att komma ifrån, problem mjukvarubranschen har brottats med länge och som hela följdsamma metodiksamlingen delvis är ett försök att komma runt, till exempel; hur får man folk att skriva dokumentation? Även om man bortser från det faktum att både anställda och chefer tenderar att prioritera ned den(fokus brukar läggas på produkten) tenderar utvecklare att tycka om att koda betydligt mer än de tycker om att skriva dokumentation och skjuter upp detta tills det är i sista stund och de bara hinner rafsa ihop något halvdant. Att dokumentation skrivs går att påverka, men kvaliteten och längden på den är svårare utan att lägga ganska mycket energi på det.
6.4.2
Visual Studio 2010 Beta 2
Ungefär halvvägs in i arbetet kom Beta 2 av Visual Studio 2010 och Team Foundation Server. Team Foundation Server 2010 Beta 2 har enligt Microsoft all funktionalitet och de erbjuder stöd för de som vill sätta den i produktionsmiljöer, vilket betyder att Microsoft anser att den är tillräckligt klar för att man kan säga till företag att de kan basera sin utvecklingprocess på verktyget. Visual Studio 2010 Beta 2 är troligen den sista versionen innan den färdiga produkten levereras. Jag bytte när Beta 2 kom men då jag knappt hade utvecklat något i beta 1 så kan jag inte avgöra om det är någon markant skilnad.
Jag har upplevt en del problem med TFS Beta 2, ibland när man försöker skapa nya projekt från Visual Studio Beta 2 hänger det sig på lite olika steg, det verkar inte gå att ta bort projekt från TFS adminkontroll och det finns en del andra problem.
6.4.3
Team Foundation Server och Team Explorer till
Visual Studio
Team Foundation Server är betydligt mindre modifierbar än väntat. Jag hittade inget sätt att bygga en modul till den utan man behöver bygga en separat webbtjänst för att kunna prenumerera på händelsenotifikationer. Samma sak gäller Team Explorer för Visual Studio, modul som hanterar kopplingen till Team Foundation Server, som har kraftigt begränsade möjligheter att lägga till funktionalitet.
Microsoft har skrivit en del om möjligheter att modifiera Visual Studio men det verkar tyvärr inte gälla Team Explorer i lika stor utsträckning. Att det inte skulle gå att lägga till en modul i TFS var lite förvånande, men jag kanske har lite höga krav på att mjukvara ska vara utökningsbar så jag vet inte hur berättigat det är. Person B uttryckte önskemål om att skippa en separat webbtjänst helt och hållet och jag håller onekligen helt med, om det hade gått att utöka TFS som jag ville hade det inte behövts men i dagsläget ser jag inget sätt att göra detta.
Den stora möjligheten till modifikationer i TFS är egna användargränssnitts- komponenter, men dessa fungerar bara inifrån Visual Studio. Detta skulle innebära
6.4 Övriga funderingar 55
att alla som ska arbeta med den nya processen behöver installera Visual Studio oavsett om de ska utveckla något eller inte. Visual Studio är ett stort verktyg och denna metod skulle troligen betyda mer utbildning än en separat webbtjänst som kan göras betydligt enklare att använda.
6.4.4
Liknelse till L
ATEX
I och med att valet av lagringsmetod för dokumentdelar föll på “Spara delat” liknar dokumentgenereringsdelen av den nya processen LaTeX ganska mycket. Om man kunde använda LaTeX som bas för det nya systemet skulle det troligen spara mycket tid på implementering men denna idé föll ganska snart.
LaTeX tar ett tag att lära sig och folk vill arbeta i sina vanliga program, till exempel Microsoft Word för ordbehandling, där de ser hur det kommer att se ut direkt och inte behöver “kompilera” texten innan. Word är trevligt och lättanvänt när man ska skriva enklare dokument, men när man har hårda regler för hur saker ska se ut, till exempel en examensuppsats som denna, verkar Word falla till korta. Några kompisar som skrivit sina examensuppsatser på Medius samtidigt som mig har haft stora problem att få till allt som de vill, problem de som skrivit i LaTeX inte verkar ha haft. Word har dock ett antal fördelar över LaTeX: ordlistor, rättstavning, stöd för kommentarer etc.
En annan fördel det skulle innebära att arbeta med LaTeX vore att det skulle gå att arbeta flera med ett dokument samtidigt. Inom mjukvaruutveckling har det skrivits program som klarar av att beräkna skillnader mellan dokument och slå samman dessa på, i nästan alla situationer, rätt sätt. Då det finns liknelser mellan filer som innehåller programkod och LaTeX-filer, båda använder filformat som är ren text utan formatering, kan man använda samma verktyg för dokumentations- hantering.
Att få folk att arbeta i LaTeX istället för Word känns dock ganska utdömt på förhand på grund av ovan nämnda skillnader vilket gör detta till inget mer än en intressant reflektion.
Kapitel 7
Slutsats
Utifrån utvärderingarnas svar tolkar jag det som att den nya processen behöver en del arbete innan den är redo, främst en koll så att den är flexibel nog för framtida behov, och det behövs en genomtänkt plan för införandet. Alla verktyg behöver också implementeras eller modifieras till det stadiet att man kan börja införa processen. Personalutbildning behöver också planeras och genomföras så att alla vet hur den fungerar och inga frågetecken kvarstår. Men när den väl är redo tror jag att den kommer att hjälpa Medius att få bättre kontroll över sin dokumentation.
Den kommer att innebära mer dokumentationsrelaterat arbete för utvecklarna än de har idag men för övrig personal kommer det troligen att underlätta, markant för företaget när alla vant sig.
Litteraturförteckning
[1] Jeff Atwood. Subscribing to team foundation server events. http://blogs.vertigosoftware.com/teamsystem/archive/2006/07/ 03/Subscribing_to_Team_Foundation_Server_Events.aspx. Hämtad. 2009-10-13.
[2] Joaquim Baptista. Agile documentation with uScrum. In SIGDOC ’08: Pro- ceedings of the 26th annual ACM international conference on Design of com- munication, pages 275–276, 2008.
[3] Barry Boehm and Richard Turner. Management Challenges to Implementing Agile Processes in Traditional Development Organisations. IEEE Software, 22(5):30–39, 2005.
[4] Chicken and the Pig. http://en.wikipedia.org/wiki/The_Chicken_and_ the_Pig. Hämtad: 2009-09-22.
[5] Common Language Infrastructure. http://www.ecma-international.org/ publications/standards/Ecma-335.htm. Hämtad: 2009-09-10.
[6] Common language runtime for .NET 4.0 Overview. http://msdn. microsoft.com/en-us/library/8bs2ecf4(VS.100).aspx. Hämtad: 2009- 09-10.
[7] Common language specification for .NET 4.0 Overview. http://msdn. microsoft.com/en-us/library/12a7a7h3(VS.100).aspx. Hämtad: 2009- 09-10.
[8] Common type system for .NET 4.0 Overview. http://msdn.microsoft.com/ en-us/library/zcx1eb1e(VS.100).aspx. Hämtad: 2009-09-10.
[9] Softhouse Consulting. Scrum in 5 minutes.
[10] Designmönstret förläggare / prenumerant. http://en.wikipedia.org/ wiki/Publish/subscribe. Hämtad: 2009-10-12.
[11] Framework class library for .NET 4.0 Overview. http://msdn.microsoft. com/en-us/library/hfa3fa08(VS.100).aspx. Hämtad: 2009-09-10.
[12] Nils Hedström. Design, implementering och utvärdering av en workflowmotor. Examensarbete, Linköpings Tekniska Högskola, 2003.
[13] Linda Rising; Norman S. Janoff. The Scrum Software Development Process for Small Teams. IEEE Software, 17(4):26–32, Juli 2000.
[14] Mira Kajko-Mattsson. Problems in agile trenches. In ESEM ’08: Proceedings of the Second ACM-IEEE international symposium on Empirical software engineering and measurement, pages 111–119. ACM, 2008.
[15] Jim Lamb. Extend visual studio team system 2010 ssc. http://stackoverflow.com/questions/1553133/extend-visual-studio-team- system-2010-ssc. Hämtad: 2009-10-13.
[16] Frank Maurer and Grigori Melnik. Agile methods: moving towards the main- stream of the software industry. In ICSE ’06: Proceedings of the 28th inter- national conference on Software engineering, pages 1057–1058. ACM, 2006. [17] Medius AB. http://www.medius.se. Hämtad 2009-09-10.
[18] Personlig kontakt med anställda på Medius, September 2009.
[19] Medius kunder. http://www.medius.se/en/referenser.html. Hämtad 2009-09-12.
[20] Microsoft. Team Foundation Server SDK Architecture. http://msdn. microsoft.com/en-us/library/bb130307(VS.80).aspx. Hämtad: 2009-10- 14.
[21] .NET Framework översikt hämtad från Code Guru. http://www.codeguru. com/dbfiles/get_image.php?id=8245&lbl=IMAGE1_JPG&ds=2004921. Hämtad: 2009-09-10.
[22] O´Reilly. Xml from the inside out. http://www.xml.com/. Hämtad: 2009- 10-13.
[23] Maria Paasivaara, Sandra Durasiewicz, and Casper Lassenius. Using Scrum in a Globally Distributed Project: A Case Study. Software Improvement and Practice, 13:527–544, 2008.
[24] LaTeX3 Project. Latexs hemsida. http://www.latex-project.org/. Häm- tad: 2009-10-14.
[25] Asif Qumer and Brian Henderson-Sellers. A framework to support the eval- uation, adoption and improvement of agile methods in practice. The Journal of Systems and Software, 81(11):1899–1919, 2008.
[26] Sukanya Ratanotayanon, Jigar Kotak, and Susan Elliott Sim. After the scrum: Twenty years of working without documentation. In Kang Zhang, George Spanoudakis, and Giuseppe Visaggio, editors, SEKE, pages 194–199, 2006. [27] What is rss? http://www.whatisrss.com/. Hämtad: 2009-10-22.
Litteraturförteckning 61
[28] Ken Schwaber. Agile Project Management with Scrum. Microsoft Press, 2004. [29] Ken Schwaber. The Enterprise and Scrum. Microsoft Press, 2007.
[30] Översikt av Scrum-processen. http://jeffsutherland.com/scrum/ uploaded_images/scrum-overview-741006.gif. Hämtad 2009-09-15. [31] Helen Sharp, Hugh Robinson, and Marian Petre. The role of physical artefacts
in agile software development : Two complementary perspectives. Interacting with computers, 21(1-2):108–116, 2009.
[32] Subodh Sohoni. Team foundation server 2010 - eventing service - sub- scribing to events. http://www.dotnetcurry.com/ShowArticle.aspx?ID= 330&AspxAutoDetectCookieSupport=1. Hämtad: 2009-10-13.
[33] Jeff Sutherland and Ken Schwaber. The Scrum Papers: Nuts, Bolts and Origins of an Agile Process. Draft 2007-10-14.
[34] Jeff Sutherland, Anton Viktorov, Jack Blount, and Nikolai Puntikov. Dis- tributed Scrum: Agile Project Management with Outsourced Development Teams. Hawaii International Conference on System Sciences, 6(7), 2007. [35] Team foundation server. http://msdn.microsoft.com/en-us/teamsystem/
dd408382.aspx. Hämtad 2009-09-08.
[36] Tfs event subscription tool. http://www.codeplex.com/ tfseventsubscription. Hämtad: 2009-10-12.
[37] Visual Studio 2008. http://www.microsoft.com/visualstudio/. Hämtad 2009-09-08.
[38] Vs10 release date. http://www.theregister.co.uk/2009/10/19/visual_ studio_2010_second_beta_packaging/. Hämtad: 2009-10-23.
Bilaga A
Funktionalitetslista
Funktionalitetslista som togs fram för den nya processen för att i grova drag se vad det ska klara av. Kravlistor går emot Scrum men jag anser att det hjälper att skriva ned vad man vill att systemet ska ha för funktionalitet för att få en bättre bild av det. Då dokumentet bara är en grov bild och inte innehåller all funktionalitet eller kommer hållas uppdaterat väljer jag att kalla det funktionalitetslista istället för kravlista.
System
Hålla koll på vilka dokumentdelar som hör till vilket dokument. Hålla koll på vilka dokumentdelar som rörs av vilka work items. Ska vara modulärt, kunna hantera flera olika filformat som txt, rtf,
doc, docx, pdf etc.
Kunna slå samman dokumentdelar till hela dokument.
Kunna generera dokument från rå information som finns i TFS:en och producera filer.
Kunna generera olika typer av dokument, release notes, changelogs etc från olika källor i TFSen.
Kunna generera dokument från dokument, t.ex. en pdf som kan publiceras från en intern doc.
Vara helt integrerat i Visual Studio 2010, ska inte krävas något separat verktyg på klientsidan.
Addon till VS10
Se vilka dokumentdelar som berörs av att man checkar in kod relaterat till en work item.
Kommunicera till servern att slå ihop de berörda dokumenten. Upptäcka att en checkin sker och hejda processen.
När en checkin sker ska den fråga användaren vad hon/han vill göra: Då dokumenten ligger på Medipedia så behöver klienten kunna ladda hem,
öppna, redigera och sedan ladda upp dokument och/eller dokumentdelar. TFS
Hålla koll på vilka dokumentdelar som hör till vilket dokument.
Hålla koll på vilka dokumentdelar som är relaterade till vilka work items. 63
Vara helt automatiserat på serversidan, det ska inte krävas något manuellt arbete i TFS:en för att processen ska rulla.
TFS-gränssnitt i VS
Visa en lista över dessa med knappar för att slå ihop enstaka dokument eller alla dokument.
Webbgränssnitt
Hantera dokument eller dokumentdelar och GUI för detta.
Hantera kopplingar mellan dokumentdelar och dokument och GUI för detta. Slå samman dokument.
Bilaga B
Svar från utvärdering
Här listas svaren ordagrant från de intervjuade personerna som nämns i avsnitt 5.3.
B.1
Person A, Utvecklare
1. Hur länge har du arbetat på Medius? i 9 månader
2. Hur skulle du, i någorlunda sammanfattad form, beskriva din ar- betsuppgift?
Utveckling och underhåll av programvara, främst webbapplikationer. 3. Vad tycker du om den nuvarande processen?
Jag tycker den fungerar bra, integrationen med Visual Studio underlättar verkligen arbetet med olika versioner av programvara.
4. Vad är ditt första intryck av den nya processen? Den nya processen verkar ganska komplicerad.
5. Tror du att det blir lättare, och i så fall vad och varför, att hålla dokument uppdaterade med den nya processen?
Det borde bli lättare eftersom man inte behöver leta reda på de relevanta dokumenten
6. Tror du att det blir svårare, och i så fall vad och varför, att hålla dokument uppdaterade med den nya processen?
Det kan bli svårt att få dokumenten att se ut som man vill när formen och innehållet är en del av en så rigid process
7. Tror du att det blir lättare, och i så fall vad och varför, att skapa översiktsdokument med den nya processen?
Se nr. 5 ovan
8. Tror du att det blir svårare, och i så fall vad och varför, att skapa översiktsdokument med den nya processen?
Se nr. 6 ovan
9. Tror du att folk kommer koppla rätt dokumentdelar till PBI:er när de skapas, om inte hur kan man underlätta det?
Jag vet inte, kanske kan man underlätta det m h a något smart system som ger förslag på dokument baserat på innehållet i den aktuella PBI’n.
10. Tror du att den nya processen kan påverka standarden för Medius dokumentation?
Ja
11. Tror du att processen kommer bli tillräckligt enkel för att du ska följa den som det är tänkt?
Det beror nog lite på hur den införs. Om man gör införandet stegvis kanske det blir lättare, t ex att man börjar med att bara koppla de nya typerna av dokument till PBI’erna.
12. Tror du att det är några delar av den nya processen kan ge problem i ert arbete, ser du några risker?
Processen verkar bygga på att det alltid ska finnas dokumentation till en viss PBI och att den dokumentationen är någorlunda sammanhållen så att den kan inkluderas där det behövs.. Jag tror det kan finnas scenarion som kräver mer flexibilitet, samtidigt är det ju en risk att “släppa” på processen om det gör att den inte följs som det är tänkt.
13. Finns det delar du tror skulle kunna förenklas eller förbättras, och i så fall hur?
Jag vill ju ha RSS för notifieringar, om det ändå ska byggas en webbservice är det ju inte så knepigt att slänga ut en feed där också kan jag tycka. 14. Saknas någon funktionalitet eller del i den nya processen?
Jag saknar ett tillvägagångssätt för hur det processen ska införas i organi- sationen. Det är särskilt viktigt eftersom väl poängen är formalisera arbetet för en del nya grupper som tidigare inte använt TFS i samma utsträckning som vi utvecklare.
15. Är någon del av den nya processen dåligt eller otydligt beskriven? Figur 4.7 till Scenario 5 - Lägg till PBI är lite oklar tycker jag, även figur 4.8 kan förbättras, det ser lite rörigt ut.
16. Utvecklare: Tror du att det är några delar av den nya processen kan ge stora problem under implementering?
I processen beskrivs hur PBI’er pekar ut dokument som ska uppdateras, dokumentens metadata lagras därmed i TFS’en. Hur går man från andra hållet? Man har ett dokument och vill veta vilka PBI’er det berör?