G.3 Teori
G.6.3 Påverkan på ett projekts olika delar
Nedan presenteras agila metoders påverkan på olika roller och faktorer som finns inom ett projekt. Detta ställs sedan med rollerna i projektet och diskuteras.
Utvecklare
Att jobba enligt agila metoder till skillnad från vattenfallsmetoden har nog störst inverkan på utvecklarna enligt M. Coram et al. [68]. Det kräver mycket från utvecklarna eftersom det är viktigt att vara bra på att kommunicera och samarbeta väl. Utvecklarna utsätts kontinuerligt för förändringar som ska tas hänsyn till och det finns inte lika mycket riktlinjer. Detta innebär att det krävs relativt erfarna programmerare för att en agil metod ska vara lämplig. [68]
Att det är viktigt med att kommunicera och samarbeta väl må vara sant men ur teamledarens perspektiv är det lika viktigt om en vattenfallsmetod används. Teamledaren har observerat flertal diskussioner där gruppen har diskuterat hur kraven från kund ska tolkas, riktlinjerna har inte alltid varit tydliga. Tack vare kundens deltagande har detta lösts genom att kommunicera dessa problem till kunden. Att det skulle krävas erfarna programmerare för att agila metoder ska vara lämpligt är inget som teamledaren har observerat utan tycker att många processer har fungerat väl.
Teamledare/Projektledare
Både teamledare och projektledare påverkas i agila metoder. Teamledaren förväntas kunna fungera som en coach och har som mål att få andra i teamet att ta initiativ. Ledarskapet är mer inriktad på att fungera genom samarbete och diskussion framför en auktoritär ledartyp. Teamledaren eller projektledaren har en mer involverad roll i agila metoder. [68]
Under projektet har projektmedlemmar vänt sig till teamledaren med olika frågor där teamledaren inte haft mycket erfarenhet men har på bästa sätt tagit reda på svaret och försökt hjälpa till. Det har naturligt skett att teamledaren har fått agera lite som coach. Teamledaren valde under projektet att agera som demokratisk ledare och i många beslut låta gruppen tillsammans bestämma. Detta gjordes för att öka förtroende till ledaren och skapa en miljö där det var enkelt att samarbeta. Teamledaren har inte någon erfarenhet med att vara teamledare i ett projekt där vattenfallsmetoden har använts vilket gör det svårt att uttrycka sig om huruvida rollen är mer involverad eller inte.
Kunder
Det är skillnad på hur aktiv kunden är under utvecklingen av ett projekt i vattenfallsmetoden och under agila metoder. I agila metoder ska kunden vara med i processen och regelbundet träffa teamet eller teamledare för att ge återkoppling. I vattenfallsmetoden är kunden generellt bara involverad i början när kravspecifikationen skapas. Eftersom kunden ska vara delaktig under hela processen, passar agila metoder nödvändigtvis inte alla projekt eftersom det ställer vissa krav på kunden att ha någon tillgänglig. [68]
67
Ur teamledarens perspektiv som bara har träffat kunden en gång under ett kundbesök så stämmer ovanstående stycke bra med hur kunden i projektet faktiskt påverkade projektet. Även om teamledaren inte var närvarande vid något kundmöte så noterades att det hölls möten. Efter varje sprint träffade några gruppmedlemmar kunden där gruppen fick återkoppling på det som hade gjorts under sprinten. Hade gruppen jobbat enligt vattenfallsmodellen hade kravspecifikationen som från början bestämts inte att ändrats och kunden hade inte fått vara med lika mycket under arbetets gång. Detta var en fördel eftersom det visade sig att kunden vid flertal tillfällen hade ändringsförslag som utfördes av oss till kommande sprint.
Teamet
Ett team som arbetar enligt agila metoder måste vara bra på att samarbeta och kommunicera. Det räcker inte med att personerna i gruppen är bra på att programmera. Som tidigare nämnt ska kunden vara delaktigt för att teamet ska fungera. Eftersom agila metoder tillåter att projekten ändras mycket under arbetsgång måste också teamet minska risken för att bli beroende av enskilda personer. Detta kan göras genom kodgranskning och att rotera arbetsområden bland utvecklarna. [68]
Under projektet tilldelade ibland teamledaren ut uppgifter till olika gruppmedlemmar. Vid några få tillfällen kunde inte vissa gruppmedlemmar närvara på grund av sjukdom eller att de var bortresta. Vid dessa tillfällen lyckades gruppen alltid lösa det genom att någon annan kunde utföra uppgiften. Anledning till detta var att parprogrammering hade bidrag till att minst två personer förstod koden bakom varje modul relativt djupgående. Resultatet av att kombinera parprogrammering och kodgranskningen hjälpte gruppmedlemmarna att ta sig an olika delar av programmet och samarbeta med varandra.
G.6.4 Generella diskussioner
Resultat för skillnaden mellan vattenfallsmetoden och agila metoder visade sig inte vara så stor som det som kanske förväntades. Det som har jämförts är kvalitet, kostnad och tidsåtgång men det ska nämnas att olika studier har använt sig av olika parametrar för att exempelvis mäta kvalitet. Detta försvårar jämförelsen. Det finns få empiriska studier som faktiskt tyder på att agila metoder är effektivare än traditionella metoder som vattenfallsmetoden. Vissa av studierna har även varit under kontrollerade miljöer och använt sig av studenter för att det har varit svårt att göra experimenten i en annan miljö. [72]
Även om det är studenter som har utfört vissa studier är resultatet intressant och i någon mån förvånande. Det finns många informella källor som förespråkar alla fördelar med att använda agila metoder men det framgår ur studierna att det nödvändigtvis inte är bättre. För att det skulle vara övertygande att agila metoder är lämpligare i mjukvaruprojekt skulle det vara nödvändigt att studierna var betydligt mer enhetliga kring resultaten. Det är endast några studier som visar på förbättringar med XP eller andra agila metoder vilket inte är tillräckligt för att dra en generell slutsats om agila metoder är bättre.
Påverkan på projektet som gruppen utförde har varit relativ stor från teamledarens perspektiv. Teamledarens tidigare erfarenheter kring grupparbete är att kommunikationen under projektets gång minskar. Personer inom gruppen är bara insatta i sitt eget arbete eller personerna som arbetar med samma sak. Teamledaren har fått bra överblick över vad alla har gjort under projektet genom Trello samt möten som gruppen haft. Detta har underlättat för teamledaren att snabbt kunna identifiera problem eller se om någon del av systemet hamnar efter i utvecklingen.
Det har varit nyttigt med retrospektivmöten eftersom de har varit ett tillfälle att sätta sig ner som grupp och göra förbättringar. Tidigare i grupparbeten har teamledaren bara reflekterat över vad som fungerat dåligt efter projektet har slutat vilket inte är lika effektivt.
68
Teamledaren märkte att eftersom alla, under stå-upp-möten, berättat vilka problem de stött på kan de också få hjälp och idéer av de övriga gruppmedlemmarna. Gruppen har tvingats till mer samarbete och kommunikation tack vare processer som förespråkas inom agil utveckling.
Agila arbetsmetoder är bra för projekt som framförallt har krav som förändras. Det förutsätter däremot krav på teamet. Även om projekt inte passar helt för agila metoder kan principer för agila metoder vara användbara. Om Teamet/kunden inte uppfyller kraven och man har ett projekt där man är säker på att kraven inte kommer komma att förändras kan en mer traditionell vattenfallsmetod vara lämplig.
G.7 Slutsats
Första forskningsfrågan kring hur agila metoder kan hjälpa till i utveckling av mjukvara besvaras i detta stycke. I projekt där kraven kan komma att förändras mycket kan agila metoder bidra med mycket. I gruppens arbete ändrades inte kravspecifikationen från att den fastställdes men återkopplingen från kund var viktigt och påverkade arbetet. Även om gruppen implementerade funktionalitet utifrån kravspecifikationen så hade kunden önskemål när denna väl såg resultatet. Genom regelbunden kundkontakt kan man se till att kunden verkligen får den produkt som önskas. Ibland kan det vara svårt att visualisera och planera alla detaljer i förväg.
Slutsatser kring forskningsfråga två och tre är att agila metoders påverkan på gruppens projekt stämmer relativt bra med resultatet från de vetenskapliga artiklarna. Kunden har fått en delaktig roll under projektets gång samt har som tidigare nämnt samarbete och kommunikation varit väldigt centrala delar under projektet. Enligt artiklar som har använts i denna studie ska teamledaren inte ha en auktoritär roll och det har skett naturligt att teamledaren har använt sig av hela teamet vid beslut som berör projektet. Den stora anledningen till detta är att mötena har varit ett bra tillfälle att fråga resten av gruppen vad de tycker och känner om olika frågor. Det som teamledaren inte märkt av är att agila metoder är svårt att utföra om gruppen bara har utvecklare som är juniorer, dvs med lite erfarenhet. Projektgruppen har inga seniorer som utvecklare men teamledaren tycker att projektet har följt och tagit nytta av de agila metoderna utan större problem. Eftersom riktlinjerna inte är lika tydliga inom agila metoder är det en stor fördel med utvecklare som har mer erfarenhet. Men projektgruppen har tillsammans tagit fram riktlinjer med kund och tagit lärdom av de misstag som gjorts.
För att besvara sista forskningsfrågan som handlar om huruvida man ska använda sig av agila metoder eller inte i ett projekt krävs omtanke. Ofta kan det vara lämpligt med agila metoder då krav under projektet kan komma att ändras under processen. Utöver detta bör projektledaren eller personen som bestämmer fundera kring hur stora team projektet ska innefatta. Detta är viktigt eftersom agila metoder ofta kräver mindre team då samarbete och kommunikation mellan alla parter är viktiga. Från resultatet har vi sett hur kunden måste vara involverad. Detta är något som man måste ta hänsyn och kolla med kunden. Kan kunden inte närvara är det kanske inte en helt agil metod man ska använda sig av.
Det finns inte starka vetenskapliga bevis för att agila metoder är bättre när det kommer till kvalitet, kostnad och tidsåtgång utan det bygger på informella påståenden.
69
8 Litteraturförteckning
[1] L. Williams, R. R. Kessler, W. Cunningham och R. Jeffries, ”Strengthening the Case for Pair- Programming,” IEEE Software, vol. 17, nr 4, pp. 19-25, 2000.
[2] Scrum Alliance, ”Learn about Scrum,” [Online]. Tillgänglig: https://www.scrumalliance.org/why- scrum. [Använd 22 02 2017].
[3] ”About Slack,” [Online]. Tillgänglig: https://slack.com/is. [Använd 24 02 2017]. [4] ”Trello,” [Online]. Tillgänglig: https://trello.com/. [Använd 24 02 2017].
[5] ”About Git,” [Online]. Tillgänglig: https://git-scm.com/about. [Använd 24 02 2017].
[6] ”About OpenCV,” [Online]. Tillgänglig: http://opencv.org/about.html. [Använd 24 02 2017]. [7] ”QT IDE,” [Online]. Tillgänglig: https://www.qt.io/ide/. [Använd 22 03 2017].
[8] Qt Documentation, ”Signals & Slots,” The Qt Company Ltd., 2016. [Online]. Tillgänglig: http://doc.qt.io/qt-4.8/signalsandslots.html. [Använd 19 April 2017].
[9] ”JSON,” [Online]. Tillgänglig: http://www.json.org/. [Använd 21 04 2017].
[10] Qt Documentation, ”JSON Support in Qt,” The Qt Company, 2017. [Online]. Tillgänglig: http://doc.qt.io/qt-5/json.html. [Använd 22 04 2017].
[11] J. Lilliesköld, L. Taxén och M. Klasson, ”Managing complex development projects - using the system anatomy,” i PICMET, Portland, Oregon, USA, 2005.
[12] ”OpenCV: Face Detection using Haar Cascades,” OpenCV, 22 04 2017. [Online]. Tillgänglig: http://docs.opencv.org/trunk/d7/d8b/tutorial_py_face_detection.html. [Använd 23 04 2017]. [13] ”GitHub,” [Online]. Tillgänglig: https://github.com/. [Använd 03 05 2017].
[14] S. Hautamäki, ”ForeVid: an Open Source Software for Forensic Video Analysis,” Tampere University of Technology, Tammerfors, Finland, 2011.
[15] R. Hughes, ”The Producer Consumer Pattern,” DZone, 26 Februari 2013. [Online]. Tillgänglig: https://dzone.com/articles/producer-consumer-pattern. [Använd 19 04 2017].
[16] Z. Zivkovic, ”Improved Adaptive Gaussian Mixture Model for Background Subtraction,” i ICPR '04
Proceedings of the Pattern Recognition, Washington, DC, USA, 2004.
[17] ”Motion Analysis and Object Tracking - OpenCV documentation,” 22 04 2017. [Online]. Tillgänglig: http://docs.opencv.org/2.4/modules/video/doc/motion_analysis_and_object_tracking.html#ba ckgroundsubtractor. [Använd 23 04 2017].
[18] P. KaewTraKulPong och R. Bowden, ”An Improved Adaptive Background Mixture Model for Realtime,” i Proc. 2nd European Workshop on Advanced Video Based Surveillance Systems,
AVBS01, 2001.
[19] A. W. B. I. M. Muhammad Ali Babar, ”Agile Software Architecture,” i Aligning Agile Processes and
Software Architectures, 2014, pp. 21-27.
[20] P. Abrahamsson, M. A. Babar och P. Kruchten, ”Agility and Architecture: Can They Coexist?,” IEEE
Software, vol. 27, nr 2, 25 2 2010.
[21] S. W. Ambler, ”The Architecture Owner Role: How Architects Fit in on Agile Teams,” Ambysoft Inc., [Online]. Tillgänglig: http://www.agilemodeling.com/essays/architectureOwner.htm. [Använd 28 03 2017].
[22] ”Role Architect,” Eclipse Foundation, 30 05 2012. [Online]. Tillgänglig:
http://epf.eclipse.org/wikis/openup/core.default.role_def.base/roles/architect_E7A12309.html . [Använd 5 4 2017].
[23] ”Artifact: Architecture Notebook,” Eclipse Foundation, 30 05 2012. [Online]. Tillgänglig: http://epf.eclipse.org/wikis/openup/practice.tech.evolutionary_arch.base/workproducts/archit ecture_notebook_9BB92433.html. [Använd 3 4 2017].
70
[24] ”Concept: Architectural Mechanism,” Eclipse Foundation, 30 05 2012. [Online]. Tillgänglig: http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/arch _mechanism_2932DFB6.html. [Använd 3 5 2017].
[25] M. Erder och P. Pureur, i Continuous Architecture: Sustainable Architecture in an Agile and Cloud-
Centric World, Burlington, MA, USA, Morgan Kaufmann Publishers, 2016, p. Chapter 4.
[26] P. Kruchten, ”Architectural Blueprints-The "4+1" View Model of Software Architecture,” vol. 12, nr 6, pp. 42-50, 11 1995.
[27] ”Introduction to OpenUP,” 30 05 2012. [Online]. Tillgänglig:
http://epf.eclipse.org/wikis/openup/. [Använd 28 03 2017].
[28] ”Template: Architecture Notebook,” 30 05 2012. [Online]. Tillgänglig:
http://epf.eclipse.org/wikis/openup/practice.tech.evolutionary_arch.base/guidances/templates /architecture_notebook_BCD3507B.html. [Använd 3 04 2017].
[29] ISO, ”ISO 9241-11:1998(en) Ergonomic requirements for office work with visual display terminals (VDTs),” 1998. [Online]. Tillgänglig: https://www.iso.org/obp/ui/. [Använd 06 04 2017].
[30] ”ISO-standarder,” Usability Partners, [Online]. Tillgänglig: http://www.usabilitypartners.se/om- anvandbarhet/iso-standarder.php. [Använd 06 04 2017].
[31] B. Albert och T. Tullis, ”Chapter 1. Introduction,” i Measuring the User Experience: Collecting,
Analyzing, and Presenting Usability Metrics, Burlington, MA, USA, Morgan Kaufmann Publishers,
2013, pp. 4-14.
[32] T. Schlatter och D. Levinson, ”Chapter 4: Layout, The Language of Layout,” i Visual Usability:
Principles and Practices for Designing Digital Applications, Burlington, MA, USA, Morgan
Kaufmann Publishers, 2013.
[33] ”What & Why of Usability,” usability.gov, [Online]. Tillgänglig: https://www.usability.gov/what- and-why/index.html. [Använd 28 04 2017].
[34] J. Nielsen, ”Chapter 6, Usability testing,” i Usability Engineering, San Francisco, CA, USA, Morgan Kaufmann Publishing, 1993.
[35] ”Intro to Distributed Version Control (Illustrated),” [Online]. Tillgänglig:
https://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/.
[36] ”Using branches,” [Online]. Tillgänglig: https://www.atlassian.com/git/tutorials/using-branches.
[37] ”Git Branching - Branches in a Nutshell,” [Online]. Tillgänglig: https://git-
scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell. [Använd 23 05 2017].
[38] S. Denning, ”Surprise: Microsoft Is Agile,” Forbes, 27 Oktober 2015. [Online]. Tillgänglig: https://www.forbes.com/sites/stevedenning/2015/10/27/surprise-microsoft-is-
agile/#e522b8e28679. [Använd 20 April 2017].
[39] israelgat, ”Scrum at Amazon – Guest Post by Alan Atlas,” The Agile Executive, 20 Juli 2009. [Online]. Tillgänglig: https://theagileexecutive.com/2009/07/20/scrum-at-amazon-guest-post- by-alan-atlas/. [Använd 20 April 2017].
[40] ”Who uses Scrum and why?,” Scrum Alliance, [Online]. Tillgänglig:
https://www.scrumalliance.org/why-scrum/who-uses-scrum. [Använd 20 April 2017].
[41] M. O. Church, ”Why “Agile” and especially Scrum are terrible,” 6 Juni 2015. [Online]. Tillgänglig: https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are- terrible/. [Använd 20 April 2017].
[42] T. Svensson, ”Konstruktion med mikrodatorer, projektkurs, 8 hp,” Linköpings universitet, 2017.
[Online]. Tillgänglig: http://kdb-
5.liu.se/liu/lith/studiehandboken/svkursplan.lasso?&k_budget_year=2017&k_kurskod=TSEA29. [Använd 4 Maj 2017].
71
[43] T. Dingsøyr, T. E. Fægri, T. Dybå, B. Haugset och Y. Lindsjørn, ”Team Performance in Software Development: Research Results versus Agile Principles,” IEEE Software, vol. 33, nr 4, pp. 106-110, Juli/Augusti 2016.
[44] P. E. Mudrack, ”Defining Group Cohesiveness: A Legacy of Confusion?,” Small Group Behaviour, vol. 20, nr 1, pp. 37-49, Februari 1989.
[45] B. Mullen och C. Cooper, ”The Relation Between Group Cohesiveness and Performance: An Integration,” Psychological Bulletin, vol. 115, nr 2, pp. 210-227, March 1994.
[46] Y. Lu, C. Xiang, B. Wang och X. Wang, ”What affects information systems development team performance? An exploratory study from the perspective of combined socio-technical theory and coordination theory,” Computers in Human Behavior, vol. 27, nr 2, pp. 811-822, March 2011. [47] A. Edmondson, ”Psychological Safety and Learning Behavior in Work Teams,” Administrative
Science Quarterly, vol. 44, nr 2, pp. 350-383, June 1999.
[48] B. D. Janz och P. Prasarnphanich, ”Freedom to Cooperate: Gaining Clarity Into Knowledge Integration in Information Systems Development Teams,” IEEE Transactions on Engineering
Management, vol. 56, nr 4, pp. 621-635, November 2009.
[49] ”Concept: Software Architecture,” The Eclipse Foundation, 30 Maj 2012. [Online]. Tillgänglig: http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/concepts/soft ware_architecture_59A08DE0.html. [Använd 7 Maj 2017].
[50] Software Testing Fundamentals, ”Test Plan,” [Online]. Tillgänglig:
http://softwaretestingfundamentals.com/test-plan/. [Använd 8 Maj 2017].
[51] J. Barlett, ”What is a Test Plan in Software Testing? (With Example),” TestLodge, 23 Juni 2016. [Online]. Tillgänglig: https://blog.testlodge.com/what-is-a-test-plan-in-software-testing/. [Använd 8 Maj 2017].
[52] M. Rouse, ”Software requirements specification (SRS),” TechTarget, 2007. [Online]. Tillgänglig: http://searchsoftwarequality.techtarget.com/definition/software-requirements-specification. [Använd 7 Maj 2017].
[53] P. Bourque och R. E. Fairley, Guide to the Software Engineering Body of Knowledge (SWEBOK): Version 3.0, IEEE Computer Society Press, 2014.
[54] ”Sprint Planning Meeting,” Mitch Lacey & Associates, Inc., 2017. [Online]. Tillgänglig: https://www.mitchlacey.com/intro-to-agile/scrum/sprint-planning-meeting. [Använd 8 Maj 2017].
[55] Mountain Goat Software, ”Daily Scrum Meeting,” [Online]. Tillgänglig:
https://www.mountaingoatsoftware.com/agile/scrum/meetings/daily-scrum. [Använd 7 Maj 2017].
[56] R. Devendra, ”Key elements of the Sprint Retrospective,” Scrum Alliance, Inc., 24 April 2014. [Online]. Tillgänglig: https://www.scrumalliance.org/community/articles/2014/april/key- elements-of-sprint-retrospective. [Använd 8 Maj 2017].
[57] ”Kanban,” Crisp AB, [Online]. Tillgänglig: https://www.crisp.se/gratis-material-och- guider/kanban. [Använd 8 Maj 2017].
[58] D. Peterson, ”What is Kanban?,” [Online]. Tillgänglig: http://kanbanblog.com/explained/. [Använd 8 Maj 2017].
[59] ”Fråga rätt!: Utveckla, testa, utvärdera och förbättra blanketter,” Statistiska centralbyrån, 2001. [60] C. J. Stettina, W. Heijstek och T. E. Fægri, ”Documentation Work in Agile Teams: The Role of
Documentation Formalism in Achieving a Sustainable Practice,” i Agile Conference (AGILE), Dallas, TX, USA, 2012.
[61] Z. S. Seyyedrezaie, B. Ghonsooly, H. Shahriari och H. H. Fatemi, ”A Mixed Methods Analysis of the Effect of Google Docs Environment on EFL Learners' Writing Performance and Causal Attributions
72
for Success and Failure,” Turkish Online Journal of Distance Education, vol. 17, nr 3, pp. 90-110, July 2016.
[62] K. Sandahl, ”Kandidatarbete för D och U,” Linköpings universitet, 24 Januari 2017. [Online]. Tillgänglig: http://www.ida.liu.se/~TDDD96/info/kandidatarbete2017.pdf. [Använd 19 Maj 2017].
[63] ”Google Docs,” Google Inc., [Online]. Tillgänglig: https://www.google.se/intl/en/docs/ about/. [Använd 21 03 2017].
[64] S. Dekeyser och R. Watson, ”Extending Google Docs to Collaborate on Research Papers,” The University of Southern Queensland, Australia.
[65] ”Office Online,” Microsoft, 2017. [Online]. Tillgänglig: https://products.office.com/en-us/ office- online/documents-spreadsheets-presentations-office-online. [Använd 21 03 2017].
[66] ”Word,” Microsoft, 2016. [Online]. Tillgänglig: https://products.office.com/en-us/word. [Använd 21 03 2017].
[67] K. Beck, M. Beedle, A. v. Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. C. Martin, S. Mellor, K. Schwaber, J. Sutherland och D. Thomas, ”Agile Manifesto,” 2001. [Online]. Tillgänglig: http://agilemanifesto.org. [Använd 28 02 2017].
[68] M. Coram och S. Bohner, ”The Impact of Agile Methods on Software Project Management,” i ECBS
'05 Proceedings of the 12th IEEE International Conference and Workshops on the Engineering of Computer-Based Systems, Washington, DC, USA, 2005.
[69] K. Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, 2000.
[70] D. Wells, ”The rules of extreme programming,” Extreme programming organisation, 1999. [Online]. Tillgänglig: http://www.extremeprogramming.org/rules.html. [Använd 28 02 2017]. [71] S. Balaji och D. M. S. Murugaiyan, ”WATEERFALL Vs V-MODEL Vs AGILE: A COMPARATIVE STUDY
ON SDLC,” International Journal of Information Technology and Business Management, vol. 2, nr 1, pp. 26-30, 2012.
[72] S. M. Mitchell och C. B. Seaman, ”A Comparison of Software Cost, Duration, and Quality for Waterfall vs. Iterative and Incremental Development: A Systematic Review,” i ESEM 2009 3rd
International Symposium on Empirical Software Engineering and Measurement, Lake Buena Vista,
73
Bilagor
1 Användartester
Test 1 Skapa projekt:
1. Skapa ett projekt med namnet “Projekt” i mappen “C:/ViAn/” med sökväg “C:/Videoklipp” 2. Lägg till videoklippet seq_01.mp4 från mappen C:/Videoklipp
3. Spara projektet
4. Stäng projektet, ta ej bort! 5. Avsluta programmet
Test 2 Ladda projekt och spela videoklipp 1. Ladda in det tidigare skapade projektet 2. Spela videon
3. Ändra uppspelningshastigheten 4. Återställ uppspelningshastigheten 5. Pausa videon
6. Rita en cirkel 7. Skriv “Hej” i cirkeln
8. Gör ett bokmärke med ritningen 9. Gör ett till bokmärke utan ritningen
10. Återuppta uppspelningen och låt den gå en stund 11. Navigera tillbaka till bildrutan med utritningen Test 3 Kör en analys och generera en rapport
1. Utför en rörelsedetektionsanalys på klippet 2. Vänta på att analysen körs
3. Visa detektionsområdena i videon
4. Gör några bokmärken under uppspelningen 5. Generera ett dokument
74
2 Formulär: Arkitekturanvändning
Del 1: Kommunikation av arkitekturen Frågor i del 1:
1. Vad är din förståelse av hur arkitekturbeskrivningen ska användas? 2. Hur tycker du att arkitekturen har kommunicerats till gruppen?
3. Hur tror du att man kan förbättra kommunikationen av arkitekturen till gruppen?
4. Tycker du att en arkitekturbeskrivning kan vara relevant för det arbete du gjort i projektet? 5. Har du några övriga tankar kring kommunikationen av arkitekturen?
Del 2: Arkitekturbeskrivningens innehåll Frågor i del 2:
1. Har innehållet i arkitekturbeskrivningen varit tydligt? 2. Har innehållet i arkitekturbeskrivningen varit hjälpsamt? 3. Vilka delar har varit hjälpsamma?
4. Saknar du något i arkitekturbeskrivningen?
5. Har du några övriga tankar kring innehållet i arkitekturbeskrivningen? Del 3: Användande av arkitekturen
Frågor i del 3:
1. Har du använt arkitekturbeskrivningen?
2. Om du har använt arkitekturbeskrivningen. På vilket sätt har du använt den?
3. Om du inte har använt arkitekturbeskrivningen, tror du att det skulle vara hjälpsamt i arbetet? 4. Har du några övriga tankar kring användande av arkitekturen?
75
3 Formulär: Git
1. Hade du använt Git tidigare innan projektet? 2. Hur mycket kunde du om Git innan projektet?
3. Har du använt något annat versionshanteringsprogram tidigare? (i så fall vad) 4. Vilken version av Git använde du, grafiskt eller inte?
5. Har du haft några problem med Git?
6. Hur tycker du att Git i sig har fungerat inom projektet?
7. Hur tycker du att det har fungerat med pull requests under projektet?
8. Hur har det fungerat med kodgranskningarna? (Tex hur de har lösts, hur många som behövde kolla på koden osv.)
9. Skulle vi kunna ha gjort på något annat sätt? 10. Tycker du att Git har påverkat projektet positivt? 11. Varför?
76
4 Enkät: Produktivitet i team
Dennaa enkät är skapad i Google Forms och distribuerad till projekt-teamet via Slack.
Beskrivning: I min individuella rapport har jag tänkt skriva om olika faktorer som bidragit till att vårt team har arbetat produktivt.
Avsnitt 1: Olika aktiviteter som kan påverka produktivitet
Beskrivning: Nedan följer ett antal aktiviteter som kan påverka produktiviteten i ett utvecklingsteam. Ranka på en skala från 1 till 5 hur mycket varje aktivitet har hjälpt produktiviteten i vårt team. Svara