Projekt Effekt Mjukvaruutvecklingsprojekt i grupp, 1DV611 Uppdragsgivare: Effect reklambyrå AB Projektgrupp 3: Peter Andersson Rasmus Karlsson Tobias Johansson Lars Wöldern Meri Stakovska
Sammanfattning Effect Reklambyrå AB (ER) vill effektivisera processen med att varje månad manuellt hämta ut statistik från sociala medier och analysverktyg för deras kunders räkning. För att ta få fram applikationen som ska hantera all denna funktionalitet har ER givit projektgrupp 3 uppdraget att skapa denna applikation. Målet är att Effect Reklambyrå med applikationen ska kunna skapa ett konto till varje kund i vår applikation och därefter hämta all data automatiskt som sedan delas in efter månader. Rollerna inom projektgruppen fördelades under uppstartsveckan och alla i projektgruppen har haft samma roller under hela projektets gång. Däremot har rollerna inom utvecklings teamen varit lite mer flytande. Projektet har genomförts iterationsvis där varje veckolång iteration ingick i Unified-Process-faserna. Gruppen hade schemalagda möten måndag till onsdag varje iteration där arbetsuppgifter delades upp bland annat. Kommunikation hölls också genom Slack utanför mötena. Applikationen är byggd med NodeJS eftersom det var det gruppen hade mest erfarenhet med, och strukturen är en klassisk klient-server modell. Grundfunktionaliteten i applikationen är på plats och projektets olika delar är väl dokumenterade. Även om det, som alltid, finns saker att förbättra så känner vi att vi lämnar över ett projekt till kunden som har goda förutsättningar att vidareutvecklas vid uppkomst av nya behov. En kund som har varit väldigt öppen för olika lösningar på problem. Detta har gjort att vi som grupp inte blivit pressade att utföra arbetet på ett visst sätt utan istället kunnat utföra arbetet på ett sätt som vi ansett varit bra för alla parter involverade i projektet.
Innehållsförteckning 1 Inledning/bakgrund 2 Syfte och mål 3 Projektorganisation 3.1 Roller 3.2 Utvecklingsteam Inception - Elaboration - Construction 3.3 Utvecklingsteam Construction - Transition 4. Genomförande 4.1 Metodik 4.2 Teknik 5 Resultat och avvikelser 6 Slutsats 7 Förslag på vidareutveckling 8 Eventuell övertagande organisation 9 Litteraturförslag/dokumentationshänvisning 10 Förslag till förbättringar inför kommande projekt
1 Inledning/bakgrund Effect Reklambyrå AB (ER) vill effektivisera processen med att varje månad manuellt hämta ut statistik från sociala medier och analysverktyg för deras kunders räkning. Exempelvis sociala medier såsom YouTube, LinkedIn och Facebook med mera. Några av analysverktygen som ska inkluderas i applikationen är Tynt och Google Analytics. Detta genom att låta bygga en applikation som automatiserar det idag manuella arbetet med att inhämta statistik från de sociala medierna och analysverktygen, för att sedan spara statistiken och presentera statistiken i en rapport på ett visuellt tilltalande sätt. Effect Reklambyrå vill även att det i statistikrapporten för applikationen ska gå att mata in egen text för att kunna sammanfatta rapporten, samt kunna ge förslag på optimering och rekommendationer till kund. Applikationen ska också kunna hantera två användarroller, admin och vanliga användare. Admin ska kunna ta fram rapporter för andra användare. För att ta få fram applikationen som ska hantera all denna funktionalitet har ER upprättat en kontakt med Linnéuniversitet. Linnéuniversitet som i sin tur gett vår grupp, projektgrupp 3 uppdraget att skapa denna applikationen. Vår projektgrupp 3 består av fem medlemmar som alla har arbetat på distans. Till vårt förfogande har vi haft 180 timmar per medlem över 12 veckor för att skapa applikationen som Effect Reklambyrå eftersöker.
2 Syfte och mål I sitt arbete med att löpande rådgiva kunder kring marknadsföring i sociala medier använder Effect Reklambyrå dessa månadsrapporter. Effects Art Director skriver sammanfattning, optimeringsförslag och rekommendation i en rapporten varje månad och diskuterar sedan dessa med kund. I nuläget använder Effect Reklambyrå 9 st olika Sociala Medier med planer på att lägga till flera. Innan vår applikation så framställde Effect Reklambyrå dessa rapporter manuellt vilket i takt med att företaget har blivit en växande uppgift. Med 20 kunder och 9 olika sociala kanaler krävs det 180 st manuella in- och utloggningar på alla olika siter och därefter manuell copy paste till excel för att skapa dessa rapporter, varje månad. Målet är att automatisera denna process åt Effect - nu kan Effect Reklambyrå skapa ett konto till varje kund i vår applikation och därefter hämtas all data automatiskt och delas in efter månader. Effect Reklambyrå kan sedan hantera alla sina rapporter på ett ställe i vår applikation och där lägga in sina rapporter.
3 Projektorganisation 3.1 Roller Rollerna inom projektgruppen fördelades under uppstartsveckan och alla i projektgruppen har haft samma roller under hela projektets gång. 3.2 Utvecklingsteam Inception - Elaboration - Construction I början av projektet har vi haft ganska fasta ansvarsområden i gruppen då det kommer till utvecklingen. Detta då det i början var mycket jobb med att upprätta struktur och rutiner för hur vi som grupp skulle arbeta under projektet. Vi beslutade att utvecklingen för front-end och back-end skulle ske i grupper om två så det fanns möjlighet att ta hjälp av varandra om något problem uppstår i utvecklingen av applikationen. På så vis minskade också risken för att utvecklingen av applikationen skulle stanna upp om någon i gruppen blev frånvarande av någon anledning.
3.3 Utvecklingsteam Construction - Transition I slutfaserna av projektet då rutiner och strukturen för testningen var etablerade så fick Peter en mer flytande roll i utvecklingen och hjälpte till där det behövdes i projektet. Testningen fortsattes också skötas av Peter. Gällande front-end och back-end blev också ansvarsområdena lite mer flexibla och alla hjälpte till där det behövdes. Det skedde även lite av ett byte i ansvaret då Meri gick över mer och arbetade på back-enden. Rasmus gick från att arbeta mer med back-enden till att jobba med front-enden. Rotationen gav lite ny energi till gruppen. 4. Genomförande Projektet utfördes iterationsvis där varje iteration pågick under en vecka. Det var tänkt att varje gruppmedlem skulle lägga runt 180 timmar på projektet, så runt 20 timmar planerades för varje iteration eftersom det var 9 iterationer totalt. Varje iteration ingick i någon utav Unified-Process-faserna, Inception, Elaboration, Construction, och Transition. I inceptionfasen upprättades kontakt med kunden Effect så tidigt som möjligt för att bestämma krav och omfattning på projektet för att sedan kunna fastställa visionen och projektplanen. Att bestämma roller i gruppen, konfliktkontrakt, och att hitta och dokumentera risker ingick också i inception. Tanken med inceptionfasen var att ta reda på om projektet är genomförbart, och möjligtvis vad som behöver göras om det inte är det. Elaborationfasen var till för att bestämma hur projektet skulle utföras rent tekniskt, alltså saker som mjukvaruarkitekturen för systemet och vilka tekniker, verktyg, och standarder som skulle användas. Själva grunden av applikationen påbörjades också i elaborationfasen. I constructionfasen var det dags att implementera systemet enligt planeringen och dokumentationen. Transitionfasen var den sista fasen och där färdigställdes all dokumentation och kod, för att sedan levereras till kunden.
4.1 Metodik Möten & Kommunikation För att få rutin på arbetet hade gruppen schemalagda tider måndag-onsdag, men fler tider lades även till vid behov. Möten/samlingar hölls under dessa dagarna på morgnarna för att alla skulle veta vad som behövde göras och vilka arbetsuppgifter de hade. Dessa mötena varierade i längd beroende på hur mycket som behövde diskuteras men för det mesta var de bra och produktiva. Som projektledare var Tobias oftast den som höll i mötena. Kundmöten med Effect hölls regelbundet med några veckors mellanrum för att ge uppdateringar på projektets framsteg och för att försäkra oss om att det inte sker något missförstånd. Varje måndag hölls det också ett handledarmöte med handledaren Tobias Ohlsson där eventuella frågor togs upp och diskuterades. Alla möten hölls i Google Hangouts med Skype som alternativ om Hangouts krånglade. Förutom mötena höll gruppen kontakt via vår Slack-kanal där samtliga var väldigt aktiva. Alla kollade Slack ofta och var aktiva vilket gjorde att vi kunde använda det för att ställa frågor och diskutera med varandra utanför mötena, och även meddela om vi inte kan vara med på mötet bland annat. Tidrapportering gjordes i Toggl. Github användes för versionshantering och även för att spara dokumentationen i wikin. Waffle.io är ett bra verktyg för Github repositorier och det användes för att hålla koll på issues. Arbetsflöde En typisk iteration var att på måndagen hölls först handledarmötet. Efter det var det oftast ett kort återkopplingsmöte för gruppen, som sedan började jobba med sina arbetsuppgifter var för sig (men höll alltid kontakt med resten av gruppen genom Slack). Arbetet fortsatte på tisdag och onsdag, eller så tilldelades gruppens medlemmar nya arbetsuppgifter på gruppmötena på morgnarna. Det var inget tvång att bara jobba på dessa dagarna eftersom var och en ansvarade mycket för att göra sina arbetsuppgifter, så arbetet fortsatte ofta resten av veckan också. 4.2 Teknik Vi bestämde oss tidigt för att göra en NodeJS-applikation eftersom det var det alla kände sig mest bekväma med, och kunden hade inte direkt några invändningar mot det. Vår applikation är uppbyggd med en ganska klassiskt klient-server modell, där servern hanterar kommunikation med databasen, autentiseringsservern, och API:erna. Express.js användes som webbapplikationsramverk, och Handlebars.js samt Bootstrap användes för att rendera i klienten.
Servern och klienten var väldigt separerade och behandlades som två skilda delar både kodmässigt och allmänt, vilket är därför dem delades upp till två olika team i gruppen, back-end och front-end. Här är ett diagram som visar de olika delarna på ett översiktligt plan. Det var först lite diskussion om vilken databas som skulle användas för applikationen, antingen Firebase eller MongoDB. Firebase var bra på att hantera realtidsdata men i slutändan valdes MongoDB med Robomongo eftersom det var det backend-teamet hade mest erfarenhet av och det verkade också lättast att sätta upp. 5 Resultat och avvikelser Systemet innefattar användarkontohantering via en tredje part och möjliggör på så sätt att kunden kan lägga upp sina användare (kundens kunder) samt hantera dessa konto i form av uppdatera, sökning, borttagning och rollfördelning. Dessa konto kan sedan användas för att logga in i applikationen där man kan autentisera sig mot sociala medier för att låta applikationen hämta statistik. Statistiken kan, i ett förhandsgranskningssteg, kompletteras med rekommendationer och förslag till förbättringar och sparas i form av rapporter. Rapporter kan ses i webbläsaren men också hämtas i pdf-format.
Konfiguration av mätdata som ligger till grund för rapport Resultatet är en nerladdningsbar PDF-fil.
Med leveransen till kund ingår, förutom själva applikationen, dokumentation för systemet. Dokumentationen är kontinuerligt framarbetad och innehåller t.ex. metoder och verktyg vi arbetat med, hur vi arbetat, vad vårt arbete är grundat på och hur applikationen fungerar samt beskrivningar på densamma. Dokumentation ger både en bred och djup förståelse om utvecklingsprocessen och dess resultat. Se full dokumentation för en mer komplett översikt. Även om en del infrastruktur för automatisk testning sattes upp så kom den inte i tillräckligt fullgott skick för att användas så mycket som det behövdes. Konsekvensen, och det vi hade velat motverka, har varit att nya ändringar påverkat gamla ändringar på ett mer svårupptäckt sätt. Testningen har istället fått ske manuellt med utgångspunkt från baskrav och övriga krav. Det har fungerat förhållandevis bra p.g.a. relativt få krav och tydlig kravdokumentation. Dock har testningen fått ske oönskat sent i utvecklingsstadiet vilket har lett till att finputsning och utseendejusteringar inte hunnit komma till sin fulla rätt. Vi har kunnat verifiera att basfunktionaliteten, baserat på de explicita krav som kunden uppgett, fungerar som tänkt. Kraven har varit tydliga och mödan har mer varit av teknisk natur än att försöka tolka kraven. Det har dock varit svårt att få tid avsatt till mer implicita krav som säkerhet och felhantering. Inför ett sista kundmöte stämde vi av att grundfunktionaliteten uppfyllts för att sedan på kundmöte återigen verifiera detsamma. Vi tror dock att det krävs mer tid för att kunden skall kunna avgöra om projektets resultat, med applikation och dokumentation, uppfyller det behov som fanns från början. Överlag anser vi oss ha levererat enligt de krav och mål som sattes upp från början, även om vissa tidigare nämnda områden inte fått all den tid de kanske skulle behöva. 6 Slutsats Kraven vi fick från kund har varit väldigt tydliga samtidigt har vi som projektgrupp fått fria händer när det kommer till val av tekniker för att kunna färdigställa applikationen. Vi har därför, som grupp, fått lägga ner mer energi och tid på att hitta rätt tekniker för att kunna uppnå funktionaliteten än för att definiera kraven. Då projektet pågår under en väldigt begränsad tid har vi därför främst baserat valet av tekniker på tidigare erfarenheter i gruppen. Detta för att reducera tiden det tar att sätta sig in teknikerna samt reducera risken för att valda tekniker inte stödjer den funktionalitet som vi sökt. På både klientsidan och serversidan har det skiftats tekniker då vi har stött på problem i gruppen. Eftersom vi baserade val av tekniker främst på tidigare erfarenhet så kom vi igång tidigt med att testa teknikerna för att se om de fungerade för projektets ändamål. Vi upprättade också väldigt tidigt i projektet ett publikt repo med tillhörande wiki på GitHub.
I wikin började vi med att dokumentera de rutiner och arbetssätt för projektet som vi kommit överens om i gruppen vilket har gjort att vi redan från början fick en tydlig struktur och kontinuitet på arbetet. Fortlöpande under projektet har vi också arbetat fram all projektdokumentation. Projektdokumentationen växte fram naturligt när den behövdes och har inte enbart gjorts för att det måste göras. I projektdokumentationen har kravspecifikationen blivit lite av ett centralt dokument som styrt mycket av den andra projektdokumenationen, exempelvis dokumentationen för mjukvaruarkitekturen och testdokumentationen. Detta då vi har satt olika id-nummer för de olika kraven som kan knytas an till i annan dokumentation. För att kunna koppla kraven till arbetet i projektet har vi också infört möjligheten att koppla tidrapporteringen samt alla issues i iterationsplanen till ett specifikt krav genom att ange ett id för vilket krav det gällde. Iterationsplanen har varit en utmaning att hålla uppdaterad och vi som grupp hade kunnat ta ett bättre gemensamt ansvar för att hålla den uppdaterad. På grund av vissa medlemmar i gruppen valde att jobba väldigt mycket en viss iteration för att sedan jobba väldigt lite en annan iteration blev också iterationplaneringen lite skev. Sköts en viss issue i iterations planeringen upp till nästa iteration på grund av detta så kunde även andra medlemmar i gruppen bli lidande av detta. Detta eftersom det för vissa issues fanns beroenden, beroenden i arbetet som innebar att om en viss del av arbetet inte var klar så påverkade detta att en annan del inte kunde färdigställas. Det gjorde att hela arbetet i slutändan blivit lite stressigt för gruppen att få ihop under slutfasen av projektet. Trots detta har gruppen i slutfasen tagit sig samman och levererat det vi lovat till kunden. Vår kund har varit väldigt förstående under projektets gång, och extra sympati kan vi ha fått eftersom vår kundkontakt tidigare har, även han, varit student på samma universitet. Vi har som grupp fått det vi behövt från kundens håll när vi frågat om det. Kunden har också varit väldigt öppen för olika lösningar på problem. Detta har gjort att vi som grupp inte blivit pressade att utföra arbetet på ett visst sätt utan istället kunnat utföra arbetet på ett sätt som vi ansett varit bra för alla parter involverade i projektet. 7 Förslag på vidareutveckling Förstärk Rådgivningsprocess med Data De krav vi utvecklat applikationen efter bygger på att exakt efterlikna rapporterna så som Effect Reklambyrå tidigare har utformat dessa. Vi misstänker att det kan vara något av en missad möjlighet - när datan har inhämtats manuellt har man inte tillgång till lika rik information som man kan få genom diverse kanalers API:er. Vi tror att Effect Reklambyrå kan hitta fler intressanta datapunkter i dessa APIer vilket skulle kunna leda till nya insikter för deras kunder. Då datan i grundkraven redan hämtas är det enkelt att även inhämta annan data då vi byggt API:erna med det i åtanke från början. Genom att närmare studera API-dokumentation tror vi att Effect komma på nya idèer med hjälp av, i dagsläget, outnyttjad data.
Eftersom det redan finns möjlighet att filtrera rapporterna så finns det inte risk för att data som är relevant för en kund men inte relevant för en annan skulle vara i vägen, utan den kan enkelt filtreras för de kunder där det är icke-relevant. Förbättra Design och Branding av Rapporter Genom att editera CSS kan Effect enkelt påverka designen av applikationen och PDF-rapporterna. Dessa kan anpassas till att ha för Effect Reklambyrå mer enhetlig branding och för att ge ett bättre intryck till kund. Utöka stöd för flera Sociala Medier Applikationen är inte begränsad till de sociala medier som finns aktiverade i dagsläget. Då varje API följer ett visst mönster och är implementerad med ett modulärt tänk är det enkelt att lägga till fler kanaler så att Effect Reklambyrå kan utöka sin rådgivning. Automatisera Leverans av Rapporter Då skapandet av rapporterna sker per automatik och datan inte enbart sparas i PDF kan Effect Reklambyrå skapa funktionalitet för att månadsvis skicka rapporter till sina kunder via e-post. Alternativt skulle en rapport automatiskt kunna skickas då en rekommendation har sparats. 8 Eventuell övertagande organisation Vår kund Effekt Reklambyrå övertar repot på GitHub med tillhörande dokumentation i wikin. 9 Litteraturförslag/dokumentationshänvisning I wikin för projektets Github-repositorie finns all nödvändig dokumentation om projektet: https://github.com/1dv611/effect-reklambyra/wiki Dokumentation till tekniker och verktyg: NodeJS: https://nodejs.org/en/docs/ Auth0: https://auth0.com/docs MongoDB: https://docs.mongodb.com/ Dokumentation till API:er: 33Across: https://platform.33across.com/api (Obs: måste vara inloggad) AddThis: http://www.addthis.com/academy/category/developer-documentation/ Analytics: https://developers.google.com/analytics/ Facebook: https://developers.facebook.com/docs/graph-api Instagram: https://www.instagram.com/developer/ LinkedIn: https://developer.linkedin.com/docs/rest-api Twitter: https://dev.twitter.com/rest/public Youtube: https://developers.google.com/youtube/analytics/
10 Förslag till förbättringar inför kommande projekt Se till att hela gruppen kontinuerligt tar ett gemensamt ansvar för att hålla iterationsplanen uppdaterad. Be alla medlemmar i gruppen att ta upp och diskutera problem som dyker upp i gruppen i ett tidigt skede och gemensamt försöka komma till en lösning. Att med hela gruppen gå igenom den totala tiden som varje gruppmedlem lägger per iteration i ett tidigt skede för att kunna fånga upp om någon gruppmedlem har en för avvikande tidsrapport jämfört med resten av gruppen. Detta för att få en jämnare arbetsbelastning under hela projektet. Skapa en överblick om vilka beroenden som finns i utvecklingen av applikationen för att tidigt kunna skjuta till mer resurser där det behövs.