Kommunal Jämförelsetjänst

Transkript

1 Kommunal Jämförelsetjänst

2 Sammanfattning Denna rapport innehåller bakgrund och information om projektet samt att vi har utvärderat hur det har gått under projektets gång. Projektet har gått ut på att vår kund Sigma ville ha en jämförelsetjänst för en kommuns produkter och tjänster så att invånarna kan jämföra dessa med varandra. Detta skulle även vara skalbart så man lätt kan sälja det till flera olika kommuner. Projektet är godkänt av kunden och både dem och vi är nöjda med slutresultatet. Bild: Resultat för jämförelse mellan två skolor

3 Innehållsförteckning Sammanfattning Innehållsförteckning Inledning/bakgrund Syfte och mål Projektorganisation Beställare Sigma IT Consulting Sweden AB Kontakt Primärt ansvarig Tekniskt ansvarig Uppdragstagare Genomförande: metodik, teknik Resultatbeskrivning/måluppfyllelse Avvikelser/efterkalkyl Slutsats varför blev det så här? Förslag på vidareutveckling Dokumentation Inför kommande projekt

4 Bakgrund Beställaren har ett flertal kommuner som kunder och det finns ett behov av en jämförelsetjänst online för blivande och befintliga invånare i dessa kommuner. De vill att man ska kunna jämföra tjänster 1 inom kommunen med varandra på kommunens webbplats, liknande den tjänst 2 som Stockholms stad erbjuder. I dagsläget är det Kristianstads kommun som är slutkunden och det är också deras data vi jobbat med. Tjänsten kommer lyftas in i kommunens EpiServer lösning efter detta projekt är avslutat och vi ska leverera kod, framförallt backend, som Sigma kan använda sig av i den fortsatta utvecklingen. 1. skolor, äldreomsorg, idrottsföreningar, båtplatser etc /Jamfor/

5 Syfte och mål Syftet med projektet är att förbättra kommunens service. Det ska vara enkelt för invånarna att hitta rätt tjänster direkt på webbplatsen. Det gör också att de inte behöver kontakta en fysisk person för att ta reda på sådan information som redan tillhandahålls i Koladas kommun och landstingsdatabas. Målet är att vi under projektiden ska bygga en tjänst som ska ta emot data från Kolada API, hantera och presentera data för att hjälpa invånare att jämföra och välja rätt tjänst. Efter önskemål kommer systemet vara byggt i ASP.NET MVC med C# och Zurb Foundation ramverk på klient sidan. Delmål finns för varje sprint internt i gruppen och efter varje sprint redovisas det för kund. Delmålen finns dokumenterade i varje sprintlog och plockas från projektets product backlog.

6 Projektorganisation Beställare Sigma IT Consulting Sweden AB Kontakt Reveljgränd 5, Växjö Primärt ansvarig Fredrik Alserin Tekniskt ansvarig Martin Tiinus Uppdragstagare Projektgruppen består av distansstudenter från LNUs Webbprogrammerare år 2. Namn Projektansvar E post Telefon Julia Sivartsson Jasmin Bejtovic Ola Franzén Andreas Bom Mattias Pavic Kund och kravansvarig jsigc09@student.lnu.se Tekniskt ansvarig jb223cp@student.lnu.se Primärt kundansvarig of222au@student.lnu.se Assisterande projektledare ab22cw@student.lnu.se 0735 Testansvarig mp222sf@student.lnu.se Caroline Forslund Projektledare / Scrum Master cf222ev@student.lnu.se

7 Genomförande Utvärdering av tidplanen Vi lyckades hålla tidplanen genom hela projektet, vilket känns väldigt bra. Alla tog sitt ansvar och lade ner den tid som behövdes för att lösa uppgifterna. Totalt sett gick det snabbare än beräknat att uppfylla projektkrav och mål. Dokumentation och tidssammanställning tog mer tid än planerat och utvecklingen av tjänsten gick något snabbare än planerat. Att dokumentationen tog längre tid än planerat var för att vi var tvungna att sätta upp mallar och rutiner själva. Likadant med sammanställningen av tidrapporteringen då det tog ett tag att hitta ett bra och effektivt sätt överföra informationen från vårt tidrapporteringsverktyg, Tracking Time, till sprintloggarna i Google Drive. Skattningen av tid blev något bättre ju längre projektet pågick. Vi tycker dock vi var ganska duktiga på det från början och det var inga problem. Dokumentation Vi tror och hoppas att dokumentationen är tillräckligt bra. Det har lagts ner mycket tid på just den delen, så att ha tillgång till mallar och rutiner från början hade underlättat. Vi skulle kunna ha lagt product backlogen och sprintloggarna i ett dokument och delat upp på flikar, det hade kanske varit smidigare för att enklare få en bra överblick. Under projektets gång insåg vi att det var svårt för utomstående (ex. vid Peer Reviews och handledning) att hitta i mapparna på Google Drive, så vi skapade en innehållsförteckning med länkar till de olika dokumenten som vi tycker har fungerat bra.

8 Kommunikation och information Informationsflödet mellan projektgruppen och kunden har fungerat över förväntan. Våra kundansvariga har tagit hand om den grundläggande kontakten. Vi har även haft veckovisa avstämningsmöten där Sigma fått se hur långt vi har kommit och även kunnat komma med synpunkter och funderingar. Vi har även haft möte med slutkunden, Kristianstads kommun, och det gick också väldigt bra. Samarbetet både internt i projektgruppen och mellan gruppen och kunden har fungerat väldigt bra. Det har verkligen känts som att vi jobbat i ett team, trots att vi suttit på olika platser. Det tog ett tag innan vi fick ordning på våra Daily Scrums. I början flöt de ihop med de längre gruppmötena, men efter input från Sigma lärde vi oss att definiera mer vad som var Daily Scrum och övriga möten. På slutet har vi inlett med en kort genomgång och sedan avslutat det mötet för att sedan fortsätta med ett längre gruppmöte då det har behövts. I början, innan vi kom igång ordentligt, tog mötena längre tid och hade säkert kunnat vara mer effektiva. Ju närmare slutet vi kommit, desto mer effektiva har vi blivit. Det beror också på att vi har satt rutinerna och vet vad vi behöver gå igenom. Vi har i snitt haft möten måndagar, onsdagar och fredagar och vi tycker att det har varit lagom, framför allt med tanke på att detta är ett projekt på halvtid. Hade det varit heltid hade man kanske velat ha dagliga Scrum möten. Riktlinjerna och kraven från kunden var väldigt tydliga. Det gjorde att det var relativt lätt att veta om vi lyckats uppnå det kunden förväntade sig. Där spelade även de veckovisa avstämningsmötena in då vi fick direkt feedback på vad vi gjort och hade på gång.

9 Förväntningar och krav Kunden säger att vi har levererat det dom har förväntat sig och att de är mycket nöjda. Vi fick tydliga krav från kunden hur de ville att vi skulle arbeta så vi har inte behövt komma med några direkta förslag på lösningar. Vi fick veta vad de ville ha och hur, så vi har implementerat det de bett om och det fungerade bra. Planering En av våra risker var att hamna efter i planeringen och missa deadlines. Planen för att förhindra det var att ha regelbundna avstämningar och att våga säga till i gruppen om man stött på problem. Det har flutit på bra och vi har inte stött på några större problem. Testning och leverans Testningen har gått bra. Det tog ett tag att sätta dokumentationen på ett önskvärt sätt men nu är vi nöjda med hur det ser ut. Vi kunde ha haft med fler kommentarer i testningen för hur det fungerat och känts rent kvalitativt. Det blev mestadels tekniskt fokuserad testning med få kommentarer på just det kvalitativa. Det finns utvecklingspotential, men systemet fungerar som det är tänkt vid slutleverans och vi oroar oss inte för att lämna över det. Vi har, som nämnts ovan, haft veckovisa avstämningar där vi demonstrerat det vi har gjort och vi har sett det som en typ av leverans. Vi har även lagt upp en testversion på kundens server så de har haft tillgång till att testa det om de velat.

10 Resultatbeskrivning/måluppfyllelse Det fanns fem baskrav i projektet och samtliga är uppfyllda. Projektet är godkänt av kunden och både dom och vi är nöjda med resultatet. Baskrav 1. Det ska gå att ställa in vilken kommun som används. 2. Man ska kunna välja en sektor som man är intresserad av t.ex skola. 3. Inom den sektorn ska man kunna välja flera olika aktörer ur en lista/karta. 4. Resultatet ska i första hand kunna visas i en tabell som jämför fakta om dessa aktörer. Alternativt ska man kunna visa vart dessa ligger på en karta. 5. Visa detaljerad information om en specifik aktör. Bild: Administratörssidan för kategorin Grundskola

11 Avvikelser/efterkalkyl Vi strök ett par krav som täcke design av tjänsten, detta för att Sigma inte var klara med en designmall till webbplatsen som tjänsten skulle integreras i. Tidigt i projektet strök vi även en risk med EpiServer. Sigma tyckte inte att det var värt för oss att sätta oss in i EpiServer under ett så här kort projekt och planerade att själva lyfta in lösningen i EpiServer efter projektets slut. Det tror vi var ett bra beslut då det antagligen hade tagit ganska mycket mer tid då vi redan hade några nya ramverk och tekniker att sätta oss in i. Slutsats varför blev det så här? Vi ser det här som ett lyckat projekt. Vi har haft högt i tak och hjälpt varandra om vi stött på problem. Regelbundna avstämningar med handledare, kund och internt har nog också varit en framgångsfaktor. Att kunden verkligen har vetat vad de ville ha levererat, samt att de jobbar inom IT och webbutveckling gör att de haft rimliga krav på vad vi kan hinna leverera inom uppsatta tidsramar. Förslag på vidareutveckling Halva vår projektgrupp kommer fortsätta med det här projektet under den praktiska delen i det självständiga arbetet. Då kommer det bl.a. att lyftas in i EpiServer och vidareutvecklas med att hämta data från ett API istället för från databasen. Det finns en del att utveckla i administrationsdelen för att systemet ska bli än mer användarvänligt och den delen kommer även läggas så man måste logga in för att komma åt det.

12 Inför kommande projekt Några saker som vi tycker fungerat bra i det här projektet och som vi kommer ta med oss till framtida projekt är: SCRUM. Korta dagliga avstämningar och att jobba i korta sprintar gör att det är lätt att se hur man ligger till. Det gillar vi. Att versionhantera på GitHub i team var smidigt så länge vi jobbade i olika filer och det är något vi kommer fortsätta med. Regelbundna avstämningar med kunden gjorde att vi fick värdefull återkoppling på det vi gjort och kunden hade även möjlighet att se om det som levererades var enligt deras förväntningar. Några saker vi kommer vilja förbättra: Att hitta en bra rutin för tidrapporteringen från början. Nu hann vi testa ett par olika sätt att sammanställa det på innan vi kom fram till vad som fungerade bra. Det gör att, tycker vi i alla fall, att det är svårt att få en bra överblick över hela projektet nu i efterhand. Testfall borde påbörjas tidigare för samtliga krav då det blir svårare och väldigt tidskrävande att göra detta i efterhand. Dokumentation Vi har en innehållsförteckning med länkar till vår projektdokumentation. Klicka på länken för att komma till dokumentet.