Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson

Transkript

1 Rapport grupp 4 Software Engineering Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson

2 Processer Sprinter Scrum har varit till stor hjälp för oss för att nå våra mål, speciellt de korta sprintarna. Korta sprinter gör att en jämn arbetsbelastning enklare kan upprätthållas vilket i sin tur gör att arbetet blir effektivare. Om det istället hade varit så att kursen använt sig av enbart en sprint på tio veckor hade det troligen blivit så att man hade tagit det lugnt de första veckorna och därmed fått stressa under den sista halvan av kursen för att hinna klart. De många och korta sprintarna hjälpte oss alltså att jobba effektivare och åstadkomma ett bra resultat. Ståuppmöten Vissa personer i gruppen hade erfarenheter, från sina tidigare grupper, av att ha ett ståuppmöte vid varje arbetstillfälle, medan andra kom från grupper där mötet lätt glömdes bort. Anledningen till att mötet lätt glömdes bort var att i en grupp bestående av enbart fyra personer så vet alla ändå vad alla gör, man kommunicerar inom gruppen hela tiden. Ett ståuppmöte är således bättre ju fler personer som finns i gruppen. De som hade bra erfarenheter av mötet tyckte att den första delen av mötet kanske inte var det bästa att lägga krut på, men att den sista delen, som behandlade vad man skulle göra idag och eventuella hinder som kan uppträda, är viktig. Projekttavla Alla i gruppen hade bara bra erfarenheter av projekttavlan. Erfarenheterna i gruppen var dock att det var tidsfördrivande att bryta ned kraven till tillräckligt många aktiviteter. Det var lätt att det blev så att aktiviteterna fortfarande var för generella när själva arbetet för etappen började. Anledningen till det var att alla i gruppen ville börja programmera så snabbt som möjligt och själva planeringen blev då lite lidande. Det blev mer att man pratade inom gruppen om man hade frågor och i vårt tycke verkar det inte ha gjort någon större skada. Burndown-diagrammet som visade hur mycket arbete som återstod uppdaterades inte alltid när något var klart utan den uppdaterades mer på måfå. För ett större projekt vore det bra med en automatiserad lösning till det här, till exempel att hantera burndown-diagrammet via en excelfil. Samarbete och gruppdynamik Den första omgången grupper var bra fördelade och ingen hade några dåliga erfarenheter därifrån. Anledningen till att gruppen var bra var tack vare en bra kunskapsfördelning. Även om man inte tog hänsyn till det här vid den andra gruppindelningen så blev även den nya gruppen relativt bra indelad kunskapsmässigt. De olika paren blev även de bra. Det gjorde att man fick kunskap

3 och erfarenheter av många olika saker. När man är fyra personer i gruppen så blir det enklare att jobba i par än om det hade varit ett ojämnt antal.

4 Metoder och tekniker TDD När det gäller TDD så var det många, om inte alla, i gruppen som hade börjat med det i sina tidigare grupper, men ju längre tiden led desto mer gick man istället över till att skriva koden först. Testerna lades sedan till i efterhand när allt redan var klart. Anledningen till det här är bara en vanesak. TDD är nog bra när man är van det, men är man inte det så känns det bara som något som förhindrar en att bli klar snabbare. Ett annat problem är att en stor del av programmet är GUI-delen som inte går att testa med Nunit. Parprogrammering Parprogrammering har fungerat olika bra inom de olika grupperna. En trend för flera grupper är att man lätt hamnar i en sits där paren blir ganska statiska. Det här togs upp under återblicksmötet vilket ledde till att grupprotationen förbättrades. Även om hastigheten kan försämras något vid parbytena så hjälper det till med kunskapsspridningen. Parprogrammeringen fungerar bra oavsett de båda parternas kunskapsnivå. För två programmerare på lika nivå så blir koden bättre och produceras snabbare medan det är gynnsamt för en programmerare med något mindre erfarenhet att hamna med en som är bättre eftersom de kan få stöd där det behövs. Frekvent integration Eftersom vi inte hade automatisk repeterad integration på servern så integrerade vi inte projektet så ofta. Normalt sett så integrerade vi projektet bara när det behövdes, vilket främst var när någon ny funktion var färdig eller när sprinten närmade sig sitt slut. Det skapade inte några direkta problem, förutom databasen, och förhindrade oss inte i utvecklandet. Designprinciper och mönster Designmönstren som har introducerats under kursen har varit till både hjälp och besvär. Vi försökte använda oss av många av dem, för att försöka göra koden lite bättre strukturerad. De nya personerna, när vi bytte grupper, kunde med det sätta sig in i programmet lite enklare. Det gjorde att det inte gick åt så mycket tid till att lära sig det nya projektet utan vi kunde sätta igång med utvecklandet i den nya sprinten nästan direkt. Designmönstren är bra i de fall de beaktas under designfasen. Att däremot försöka designa om applikationen för att dra nytta av ett mönster är väldigt tidsödande. Man bör därför väga tidsåtgången mot de fördelar mönstret kan ge. Ett annat misstag är att använda vissa mönster utan att bekräfta att behovet är stort nog, exempelvis för en abstract factory. I vårt ärvda projekt kändes det som

5 om koden hade varit enklare att hantera och underhålla om man hade valt en simplare lösning. Refaktorisering Refaktoriseringen gick bra och var välbehövlig, särskilt när man bytte grupper. När man har arbetat med något under flera veckor så är det lätt att man blir hemmablind. Vid bytet av grupperna så kom det in personer med nya ögon och de hittade en hel del saker som kunde tas bort eller förändras till det bättre. Det gjorde att den tekniska skulden minskade och kvalitén på koden blev bättre. Vi märkte emellertid av i vissa grupper att refaktoriseringen gärna blir nedprioriterad. När vi har kommit på det själva är det dock något vi har tagit itu med. Verktyg Nunit Till en början var det krångligt att få Nunit att fungera. Det var en hel del steg som behövdes gå igenom och det tog en del tid innan det började fungera som man ville. Men när man väl fick det att fungera så var det enkelt att använda. Ett problem med Nunit är att det inte fungerar över nätverksenheter vilket får följdproblem eftersom vi då måste checka ut koden på den lokala disken. Visual Studio Visual Studio har varit till stor hjälp, men även till en del besvär. Verktyget gjorde det enkelt och snabbare att bygga upp ett gränssnitt. Det var bara att dra in komponenterna från verktygslådan istället för att behöva skriva koden bakom själv. En annan bra sak med Visual Studio och liknande utvecklingsverktyg är den hjälp man kan få, bland annat med refaktorisering och uppslag av funktioner och variabler i en klass. Integrationen med Subversion var också väldigt smidig. Någon i gruppen hade dock stött på ett problem med Visual Studio i kombination med Subversion. För ändrade man namn eller flyttade på filer i Visual Studio och sedan försökte commita det så ledde det till en del krångel. Problemet löste sig till slut, men vet egentligen inte varför problemet inträffade. Antagligen var det för att flera personer hade försökt att ändra samtidigt. Visual Studio kan ibland vara för hjälpsamt. När man vill lägga till en databas så poppar det upp en guide för att lägga till ett dataset. Den naturliga reaktionen om man inte känner till programmet är att tacka och ta emot. Tyvärr så sitter man sedan med ett dataset som man kanske inte har användning för och som är betydligt krångligare att bli av med. Subversion

6 Precis som de flesta andra verktyg som man inte har använt tidigare så var även Subversion krångligt till en början. Men allteftersom man lärde sig hur det fungerade så förenklade det utvecklingsarbetet rejält. Vi märkte en hel del skillnader mellan grupperna i hur vi använde verktyget, främst vad gäller kommentarer av commits, men också vad grupperna tillåter att man kör commit på. Vissa av grupperna tillät inte commits om inte hela projektet fungerade att kompilera medan andra grupper använde commits som en sorts save-knapp vilket ibland kunde leda till att projektet blev instabilt för alla i gruppen. En annan stor skillnad låg i användandet av kommentarer, vilket var ett nytt begrepp för vissa grupper. Msbuild Efter att Msbuild väl kommit i drift på integrationsservern så har verktyget fungerat bra. Databas (Access) När det gäller databasen så hade alla i gruppen erfarenheter av krångel. När man körde Windows klienten så kopierades databasen till bin-mappen, medan när man sedan körde det webbaserade så använde den sig istället av en annan. Sedan var det även problem med att få kopplingen till databasen att fungera på intergrationsdatorn. När det gäller lösning på det här så fanns en del olika erfarenheter. I en grupp så använde man sig av två olika sökvägar. En sökväg när man jobbade på de vanliga datorerna och en annan när man körde programmet på integrationsdatorn. Det gjorde dock att blev en del bytande fram och tillbaka. När vi sedan bytte till de nya grupperna så hittade vi ett bättre sätt att lösa det på, vilket gjorde utvecklandet lite enklare. En bättre och mer verklighetsbaserad lösning hade varit att tillhandahålla en gemensam databasserver som grupperna kunde använda. Detta behövs kanske inte ifrån början av projektet, men däremot borde det finnas möjlighet att använda en databasserver från det att vi blandar in webgränssnittet eftersom det skulle eliminera många av de problem som grupperna stötte på.