Fakulteten för ekonomi, kommunikation, IT & data Labrapport över Rumbokningssytemet Grupp:1 Kurskod: DVGC18
Kursnamn: Software Engineering Inlämningsdatum: 2009 10 28 Scrummaster: Martin Blom Projektmedlemmar: Erik Andersson, Derrick Eriksson, Erik Jansson, Johan Käll & Angelika Palm Inledning Laborationen gick ut på att skapa ett rumbokningssystem för både windows och webb. Windows applikationen är speciellt riktad till administratören av systemet. Som inloggad i systemet finns olika behörighetsnivåer. Administratören ska ha befogenheter att göra allt i systemet; som att boka, ta bort bokning, lägga till rum och inventarier, lägga till mat & dryck etc, medan en vanlig användare av systemet endast ska kunna boka och ta bort sina egna bokningar med eller utan catering. Vissa användare är enbart behöriga till att se bokningslistan, detta gäller främst personal som iordningställer rum samt städar. Arbetsform Laborationen genomfördes som projekt med 4 projektgrupper, 5 6 personer i varje grupp. Varje grupp var indelad i olika kompetensnivåer såsom design, användarkrav, testning och kodning. Varje projektgrupp skulle arbeta agilt och använda sig av Scrum. Projektet var indelat i 4 sprintar och 4 demo tillfällen, som genomfördes varannan fredag. Innan varje ny sprint gicks backlogen igenom med produktägaren för att bestämma vilka användningsfall som skulle hinnas med de 2 närmsta veckorna och sedan demonstreras i slutet av sprinten. Vi skulle även poängsätta användningsfallen i förhållande till storlek. Grupperna skulle sedan genomföra dagliga stå upp möten, programmera enligt TDD samt rotera med parprogrammeringen. För att verkligen få känna på hur det kan vara att komma in i ett redan påbörjat projekt, fick alla byta grupper i sista sprinten. Scrum Projektet följde Scrum hela vägen och vi har upplevt det som en bra arbetsmetod när alla gruppmedlemmar kan känna sig mer delaktiga i flera delar och man får en bättre insikt. Varje Sprint varade totalt 5 arbetsdagar vilket vi inte upplevt som en optimal längd men ändå i rätt proportion till kursen och projektet. Innan varje sprint gicks backlogen igenom med kunden, som i vårt fall agerades av läraren, vi fick på så vis chansen att direkt fråga över oklarheter över användningsfallen. Det svåra var att poängsätta varje användningsfall, då de små ibland visade sig bli större och tvärtom. När halva projektet gått skulle vi helt plötsligt börja poängsätta användningsfallen på ett annat sätt, vilket skapade en hel del förvirring. Det hade varit betydligt lättare om det hade varit klart och tydligt från början hur man skulle gått tillväga med poängsättningen. Det är dock ett bra sätt att arbeta på när väl man kommer in i det.
Att tillsammans med projektgruppen sätta sig och bryta ner användningsfallen i mindre delar var otroligt lärorikt. Sättet att skriva ned varje användningsfall på en stor post it lapp och de nedbrutna delarna på mindre post it lappar gjorde att man fick en otroligt bra överblick över vad som skulle göras. Det är viktigt att skriva ner ID nummret på de stora respektive de små lapparna, vid många användningsfall blir det mycket att hålla reda på, för att lättare se vilka som hör ihop. Lapparna flyttades sedan på tavlan efterhand som någon började på dem eller att de blev klara. Vi anser att tavlan med post it lapparna är något som verkligen gör Scrum tydligt, då alla i projektet hela tiden vet vad som är på gång genom att titta på tavlan. I Scrum ingår varje dag ett litet timeboxat stå upp möte där alla ska ta upp vad de har gjort dagen innan, vad de ska göra idag och om det har uppstått några problem. Vissa i gruppen tyckte att de dagliga stå upp mötena var överflödiga medan andra tyckte att det var ett bra sätt att få en uppfattning om i vilket stadie projektet befinner sig i. Demo delen som ingår i Scrum och som alltid måste genomföras, oavsett vad som inträffar, vid samma tidpunkt efter varje sprint är ett väldigt bra sätt att alltid komma framåt i projektet. Man får med demonstrationen snabbare reda på om det finns fel i systemet och inget kommer som en överraskning vid slutleverans till kund. Kunden blir hela tiden uppdaterad över hur arbetet flyter på och kan samtidigt påpeka om något behöver göras om under projektets gång. Ett otroligt bra sätt att jobba på för att få kunden involverad och förhoppningsvid mer nöjd, minskar även problemen med förseningar. Scrum är med andra ord en väldigt lovande arbetsform som vi gärna testar på fler gånger. Samarbete och gruppdynamik Scrum har ett bra sätt för att få till ett bra samarbete mellan alla gruppmedlemmar. Det fungerar på det viset att gruppen gör en cirkel med projektmedlemmarnas namn runt och sedan dras streck mellan de som jobbar/jobbat ihop. Ett effektivt och väldigt överskådligt sätt för att se vilka som jobbat mest tillsammans. Genom att rotera så bryts mönstret och alla får på så vis chansen att jobba med alla. På så sätt sprids kompetensen mellan alla personer i projektet. Då vissa grupper bestod av fem personer var det lite svårare att få till parsamarbetet, blev istället 3+2 eller 2+2+1. För att uppnå bästa resultatet tror vi att gruppen ska bestå av jämnt antal deltgare vad gäller programmerare. Samarbetet i vår grupp var väldigt bra och att byta grupp var intressant, då vi på det viset fick se hur annorlunda samma program kan vara och hur jobbigt det är att lära sig andras kod. Då alla hade olika erfarenheter fick man hela tiden lära sig nya saker av varandra. Metoder och Tekniker Parprogrammering Parprogrammering är en väldigt bra metod, men precis som vi nämnde under samarbetet tror vi projektet får ut bästa resultatet om det är jämnt antal programmerare. Att hela tiden rotera
med vem man parprogrammerar med är positivt, men vid vissa tillfällen kan det även vara svårt. Vi tänker då främst på att alla har olika erfarenheter och olika arbetsområden. Vi upplevde under projektets gång att de som gillar exempelvis databaskopplingar oftast sätter sig med det menas andra som kanske har lättare för själva GUI delen, tar det ansvaret. Att rotera med alla tror vi i praktiken kan bli svårt, även om det är önskvärt. Vid parprogrammering är det även otroligt viktigt att byta plats, och även detta var något som inte alltid uppfylldes fullt ut, då vissa personer helt enkelt kommit längre och var bättre på att programmera. TDD Ett helt nytt tänk som de flesta av oss inte var vana vid och som ställde till många problem samt en del frustration. Tyvärr hände det många gånger att TDD sköts åt sidan, för att sedan återupptas längre fram. Vi hade önskat att TDD gåtts igenom bättre på föreläsningarna, då det förmodligen gjort att vi använt TDD flitigare, det är ju trots allt ett bra sätt för att hela tiden kontrollera koden. TDD är bra och otroligt effektivt för de krångliga funktionerna, men känns inte riktigt nödvändigt för allt. Om man ska se det från ett större perspektiv, så undrar vi över hur många företag som skulle använda sig av TDD under ett projekt där alla är nybörjare. Rent teoretiskt kanske det funkar men inte praktiskt. Frekvent integration I slutet på varje sprint sätts systemet i drift på en integrationsdator för att kund ska ha något konkret att ge synpunkter på. Syftet var också att kund ska kunna testa och delvis använda systemet under hela utvecklingsprocessen, allt för att få en stegvis övergång i det nya systemet. Systemet kommer samtidigt ut i verksamheten vilket bordar för att svagheter eller rena falaktigheter upptäckes tidigare i utvecklingen av systemet. Designprinciper och mönster Alla principer och mönster var svåra att ta till sig när vi inte kunde se nyttan i det från början. Blev på det viset lite negativt inställda till deras användning, samtidigt som mapper mönstret var svårt att testa med TDD. Efterhand som programmet blev större så kunde vi till slut se nyttan i att använda sig av till exempel mappers klasser, men det hade skapat bättre förståelse om man under föreläsningarna gått igenom tydligare och bättre exempel. Refaktorisering Refaktorisering är något vi tycker att alla programmerare ska använda sig av, oavsett om man arbetar agilt eller inte. På det viset slipper man onödiga upprepningar och får en snygg och städad kod att lämna efter sig. Det blir då lättare för utomstående att sätta sig in i koden, samt lättare att återuppta sin egen gamla kod.
Verktygen Accessdatabas Vi var tvugna att utvidga databasen med fler tabeller och det svåra blev att få till alla kopplingar mellan tabellerna på rätt sätt. Det största problemet med acessdatabasen låg i att få både webb och windows applikationen att använda sig av samma databas och att få till sökvägarna. Problemet skulle gått att undvika om alla databas anrop fått köra mot en gemensam server databas istället för en lokal databas. Vi löste det genom att skapa ett lokalt namn som pekade på databasen och namnet kunde sedan anropas från olika ställen i koden. Visual Studio Programmeringspråket C# liksom Visual Studio var nytt för de flesta av oss och att lära sig Visual Studio när man kommer från Eclipse var jobbigt, speciellt då programmet har en förmåga att motarbeta MVC. Det uppstod emellanåt tekniska problem, som att få alla program att fungera, vilket ledde till att små aktiviteter blev större. NUnit Att få ihop heltäckande tester på hela systemet var svårt, detta med tanke på att GUI inte direkt går att testa. NUnit som program är dock väldigt smidigt när man väl får det att fungera, och det är ett bra verktyg för enhetstestning. SubVersion Kompileringen till SVN skapade många gånger problem, då det fungerade ibland och ibland inte. Detta berodde till stor del på att projektgrupperna hade skapat olika namn på sina projekt när de sparat dessa till SVN servern. Detta hade inte framgått från start och hade givetvis minskat ner en massa onödig tid och frustration. Upptäckte framåt slutet att vi använt SubVersion på lite fel sätt, då vi aldrig skapat nya versioner av våra projekt utan uppdaterade istället samma version hela tiden. Verktyget blev på så sätt mer ett kollaborationsverktyg istället för en versionskontroll. Även detta problem hade undvikits om vi fått mer information från start.