University College Nordjylland Teknologi og Business

Transkript

1 University College Nordjylland Teknologi og Business Datamatiker Dmaa Semester Afsluttende projekt Projekt deltagere: Ulrik Larsen In this project I have developed a Magento website: a furniture and decoration store in Aalborg. The main goals of this project have been to gain an understanding of Magento and to adapt and improve Magento based on customer specifications. Secondly objectives were to find cases where Scrum and XP practices have been implemented well on Solo teams. Vejledere: Ann Francke Riisberg Afleveringsdato: Underskrifter: During the process I have learned a lot about Magento and achieved my goals, to understand how it works and to adapt and improve Magento to the customer needs. Scrum and XP practices have helped me during the project, to keep structure and achieve a high quality of work. The project will be finished after the end of this rapport by working freelance for the company. Hopefully doing so evolving the Scrum and XP practices used here. Ulrik Søvsø Larsen

2 Indholdsfortegnelse Indledning...1 Læsevejledning...1 Teori...2 Indledende Magento...2 Teknologi stack...2 Drupal...2 Apache...2 MySQL...3 PHPMyAdmin...3 HTML...3 PHP...3 Filtype PHP...3 Filtype PHTML...3 CSS...4 SCSS...4 JavaScript...4 jquery...4 Arkitektur...4 Objekt orienteret programmering...4 Domæne model lags arkitektur...6 GRASP (Elaboration fasen, analyse og design)...6 MVC - Model View Controller...7 Magento...7 Zend Framework...7 PHP i Magento...7 Cache i Magento...8 Arkitektur i Magento...9 Konceptuel struktur...9 Pakker og Temaer Folder struktur Fallback i Magento Moduler Dokumentation i Magento Magento - MVC - Model View Controller Magento ORM Data modeller EAV Model Debug i Magento xdebug i Magento Integration / API Teknologi FTP phpmyadmin... 19

3 Lokal Bitnami VM med Magento Test server Opdateringsproces Backup IDE Atom Visual Studio PHPStorm Risici registrering Udviklingsmetoder Scrum Scrum hoved principper: Scrum begreber og processer Roller Artefakter Ceremonier Scrum begreber og proces forløb Scrum Buts Solo Scrum XP XP Praktikker XP Værdier Solo XP Projekt Metode valg Implementering af Scrum Scrum But Projekt Implementering af XP praktikker Produkt Backlog Sprint Sprint Sprint planning Retrospektive Burndown Hvad gik godt? Hvad kunne have været bedre? Hvad overraskede? Sprint Sprint planning Review Retrospektive Burndown Hvad gik godt? Hvad kunne have været bedre? Hvad overraskede? Sprint

4 Sprint planning Review Retrospektive Burndown Hvad gik godt? Hvad kunne have været bedre? Hvad overraskede? Sprint Sprint planning Review Retrospektive Burndown Hvad gik godt? Hvad kunne have været bedre? Hvad overraskede? Sprint Sprint planning Retrospektive Burndown Hvad gik godt? Hvad kunne have været bedre? Hvad overraskede? Sprint Sprint planning Retrospektive Burndown Hvad gik godt? Hvad kunne have været bedre? Hvad overraskede? Sprint Sprint planning Review Retrospektive Burndown Hvad gik godt? Hvad kunne have været bedre? Hvad overraskede? Samlet risici vurdering Samlet perspektivering Magento Scrum Roller Ceremonier Artefakter XP Praktikker Løbende integration... 46

5 Refaktorering Kodestandard Test først udvikling Videre udvikling Magento Konklusion Referencer Bilag... 53

6 Indledning Denne opgave tager udspring i mit praktikforløb hos Kalejdoskop, som er en møbel- og interiørbutik i Aalborg. Kalejdoskop har en eksisterende Magento CMS webshop: som de ønsker at opdatere og udbygge. Arbejdet med Magento webshoppen har ført til en stor interesse for Magento samt arbejde med webshop udvikling. Derfor har jeg valgt at have Magento, som fokusområde i denne rapport. Målet med projektet er, at: Lære og arbejde med ny teknologi Magento o Hvad er Magento, og hvordan er Magento opbygget? o Tilpasning af Magento design og layout ud fra kundens behov. o Kunne udbygge Magento med ny funktionalitet. Hvordan kan Scrum og XP praktikker understøtte processen, når der arbejdes alene. For at løse problemerne vil jeg finde og beskrive de teknologier, som Magento gør brug af, samt finde ud af hvordan Magento er opbygget. Derudover vil jeg benytte Scrum og XP praktikker i udviklingsprocessen i så vidt muligt omfang, det er muligt. Jeg har en fast kontaktperson hos Kalejdoskop til at varetage rollen som Product Owner i projekt perioden, og jeg vil selv agere Scrum Master og team. Da jeg arbejder alene, vil jeg ligeledes indsamle viden om Scrum og XP praktikkers brugt i solo projekter. Læsevejledning Teoriafsnittet er indrettet, så der først beskrives de teknologier, Magento bygger på - herefter detaljeret om Magento. Sidst beskrives udviklingsmiljøerne Scrum og XP samt fundne eksempler på Solo Scrum og XP. Projektafsnittet starter med metodevalg, herefter Product Backlog for projektet. Så kommer sprint, hvor hvert sprint er dokumenteret med Sprint planning og Retrospektive for sprintet. Review er noteret, hvis det har været særligt interessant. Sidst i projekt er samlet risici vurdering og samlet perspektivering. I videre udvikling beskrives fremtiden for projektet efter denne rapport. Afsluttes med konklusionen. Udarbejdet af: Ulrik. Side 1 af 53

7 Teori Indledende Magento Magento er en CMS 1 til e-handelshjemmesider. Der findes forskellige udgaver af Magento, både betalt og gratis udgaver. I dette projekt er brugt Magento Community Edition, som er en open source udgave. Magento består af Magento framework, som kan moduleres efter behov. Magento framework tilbyder det basale for at kunne drive en e-handels butik, i form af forretningslogik, dataadgang og basisklasser. Magento kan udbygges med eksterne moduler, som kan føjes til eller erstatte funktioner. På Magento hjemmeside har jeg fundet, at Magento kræver en LAMP eller LNMP stack for at fungere. Henvisning til stacken er et akronym, der dækker over hyppigt brugte open source programmer. I Tabel 1 kan man se informationer for live- og testserverne. Operativ system: Ikke oplyst Web Server CMS: Drupal Web Server: Apache 2.x Database: MySQL 5.6 PHP: PHP 5.4 Tabel 1 - Live og test server informationer Lokalt har jeg brugt en Bitnami Virtuel Maskine, hvor jeg har haft Magento kørende i en Mac (MAMP) og Windows PC (WAMP). Teknologi stack Drupal Drupal er et open source CMS system til at håndtere hosting af websites. Drupal bruger PHP 2 og MySQL. Apache Apache er en open source web server. Apache er meget populært, da det er open source og fungerer på mange forskellige platforme. Ud fra analyse lavet af w3techs.com [1], bruges Apache i dag på over 55% af alle web servere, som de kender til. Apache 2.x understøtter fortolkning af PHP. 1 CMS - Content Management System 2 PHP - Hypertext Preprocessor Udarbejdet af: Ulrik. Side 2 af 53

8 MySQL MySQL er et open source RDBMS 3 udarbejdet af Oracle. MySQL er et meget brugt system som web database, og det indgår, som nævnt, som M i open source stacks. MySQL fungerer flertrådet, hvilket appellerer til web brug, hvor der må formodes at være mange samtidige efterspørgsler. PHPMyAdmin PHPMyAdmin er en open source administrativ web portal GUI, til håndtering af forespørgsler til MySQL. PHPMyAdmin er særligt anvendeligt til at få et visuelt overblik over databaser og forespørgsler. I projektet har jeg brugt PHPMyAdmin til administration af MySQL databasen. HTML HTML 4 er et sprog, der beskriver hjemmesiders struktur. I HTML dokumenter finder man således information om, hvad og hvordan elementer skal vises. Det er op til klientens browser at tolke indholdet og vise det til brugeren. PHP PHP er et open source server-side script sprog, hvilket betyder, at brugeren ikke ser PHP koden, men kun resultatet af koden. PHP bruges primært i forbindelse med web programmering og kan inkluderes på html sider. PHP skal, fordi det er server-side kode, fortolkes af serveren, og den sendes derefter til klientens browser. Filtype PHP Filtypen PHP bruges til at håndtere PHP kode logik. Filtype PHTML Filtypen PHTML bruges til at håndtere rå HTML og PHP. PHTML bruges dermed til at skabe den visuelle præsentation, mens PHP inddrages efter behov til at håndtere logik. 3 RDBMS - Relationel Database Management System 4 Hypertext Markup Language Udarbejdet af: Ulrik. Side 3 af 53

9 CSS CSS 5 er et præsentations sprog, der bruges til at beskrive, hvordan Markup sprog, så som HTML, skal præsenteres. CSS kan både forekomme som en integreret del af Markup koden og som et eksternt dokument. Det er bedst at holde CSS og HTML adskilt, da det er nemmere at vedligeholde og cache hver for sig. SCSS En anden måde at arbejde med CSS er ved at bruge SCSS 6. SCSS er en udvidelse til CSS, som tilfører mere funktionalitet til udvikleren. For at bruge SCSS skal det kompileres til CSS, så der ikke er en forskel for brugeren. Med SCSS kan man eksempelvis bruge variabler og lagrede inkludes. Det letter i høj grad arbejdet ved større CSS filer i høj grad, da man kan opdele CSS filen i sigende segmenter og inkludere efter behov. Herved undgås også kode repetition. Desuden kan brugen af variabler lette arbejdet med CSS, så koden bliver lettere at overskue og vedligeholde. Til dette projekt har jeg brugt SCSS, da Magento 1.9 responsive tema implementere denne. SCSS er en alternativ syntax til SASS. JavaScript JavaScript er både et objektorienteret script sprog, som anvendes typisk client-side på hjemmesider. Endvidere kan JavaScript bruges til at tilføje ekstra funktionalitet, så som animationer eller ændring af elementer eller til at tilføje struktur efter HTML sider er konstrueret. jquery jquery er et kraftfuldt JavaScript bibliotek. Med jquery kan man blandt andet, finde og manipulere specifikke DOM 7 elementer. Arkitektur I det følgende beskrives mønstre, der bruges til at fastsætte arkitekturen. Objekt orienteret programmering Objekt orienteret programmering er en design filosofi. Hvor man arbejder på at opdele domænets objekter i afgrænsede klasser med fælles attributter, struktur og adfærdsmønster. 5 Cascading Style Sheets 6 Sassy CSS 7 Document Object Model Udarbejdet af: Ulrik. Side 4 af 53

10 Domæne model En domæne model er en konceptuel model af den virkelige verden ud fra en bestemt problemstilling. Domæne modellen bruges til at opdele verden i konceptuelle klasser og vise deres relationer. Det har ikke været muligt at finde en Domæne model for Magento. Derfor har jeg valgt at lave en selv, i Tabel 2. Domæne modellen har udgangspunkt i ordren. Tabel 2 - Domæne model Magento Udarbejdet af: Ulrik. Side 5 af 53

11 3 lags arkitektur 3 lags arkitektur er en model til at opdele systemet for at holde ansvarsområderne adskilt. Et typisk eksempel er vist i Tabel 3. Der må kun være synlighed lagene imellem, med undtagelse af præsentationslaget der kan medtage modeller fra model laget i præsentation. 3 lags arkitektur Præsentations lag Applikations lag Domæne lag Tabel 3 - Eksempel på 3 lags arkitektur GRASP (Elaboration fasen, analyse og design) GRASP 8 hjælper med at standardisere ansvarsfordelingen mellem klasserne ved fastsættelse af arkitekturen. Det foregår primært ved brug af specialiserede controllere og model klasser. Ved brug af GRASP opnår man høj binding og lav kobling i systemet. Niveauet af binding fortæller om, hvor afgrænsede klasserne er i forhold til deres specifikke område. Målet er at have mange specifikke klasser, med let genkendelige navne, som kun indeholder den nødvendige kode for at kunne udføre sit område. Ved denne opdeling bliver klasserne lettere at genkende, genanvende, udskifte og vedligeholde. Niveauet af kobling dækker over, hvor afhængige klasserne er af hinanden, hvor målet er, at klasserne ved en lav kobling er uafhængige af hinanden og derved let kan skiftes ud. 8 General Responsibility Assignment Software Patterns Udarbejdet af: Ulrik. Side 6 af 53

12 MVC - Model View Controller MVC er et mønster som dikterer, hvordan synligheden skal være i mellem de forskellige lag. MVC er opdelt i tre lag: Model, View og Controller. Et af hovedprincipperne er, at Model-laget ikke skal have direkte synlighed til View-laget. Ved at holde lagene adskilt bliver overblik og vedligeholdelse meget nemmere. Desuden vil det være muligt at udskifte lag efter behov. Ved brug af Model-objekter i View skal der bruges View-modeller som kun indeholder den nødvendige information, frem for systemets Model objekter, med forretnings logik. Igen for at holde lagene adskilt, men også for kun at præsentere det nødvendige data. Magento I det følgende vil jeg beskrive nogle af de centrale dele af Magentos opbygning. Zend Framework Magento bruger Zend framework 1. Zend er et open source, objekt orienteret web framework til PHP 5. Zend er modulerbar og bruger MVC arkitektur. PHP i Magento I Tabel 4 - Eksempel fra PHP kode til Resultat på skærm ses et eksempel på brugen af PHP i Magento. Der er en klar fordel ved at bruge PHP og Html sammen på denne måde. Med HTML kan man kontrollere, hvordan elementer skal præsenteres, og med PHP hvad de skal indeholde. Der er en sikkerhed i, at PHP kildekoden kun er synlig på serveren, og at siderne altid laves på samme måde. Ulempen ved PHP må være, at siden er statisk, når den bliver leveret til brugeren. Så hvis der skal ændres i koden hos brugeren, bliver man nød til at bruge et klient-side sprog, eksempelvis JavaScript. PHtml kode på server: Udarbejdet af: Ulrik. Side 7 af 53

13 Resultat i browser Debugging elements: Resultat på skærmen: Tabel 4 - Eksempel fra PHP kode til Resultat på skærm Cache i Magento Magento gør brug af cache for at optimere driften. Man kan i Magento vælge, hvad man ønsker at cache, Tabel 5 viser en liste over, hvad Magento tilbyder som standard: Type Konfiguration Layout Blocks HTML output Oversættelser Samlings Data EAV types og attributter Web Services Configuration Beskrivelse System (config.xml, local.xml) og modul konfigurations filer(config.xml). Layout bygnings instrukser. Side blocks HTML. Oversættelses filer. Samlings data files. Entity type deklarations cache. Web Services definitions filer (api.xml / api2.xml). Tabel 5 - "Magento cachelager" Ud over de ovennævnte cache muligheder, laver Magento cache af: Katalogbilleder, Swatch billeder, JavaScript og CSS. Udarbejdet af: Ulrik. Side 8 af 53

14 Ud fra elementerne kan man se, at det er statiske elementer i Magento som caches. Det giver god mening, så der ikke skal ledes i systemet, hver gang der foretages en forespørgsel. Cache genereres første gang der laves en forespørgsel, hvor der ikke er lavet cache. Magento giver besked, når en eller flere cache elementer er forældet, så er det op til administratoren af forny cache, hvis det er ønsket. Arkitektur i Magento I det følgende beskrives Magentos arkitektur. Konceptuel struktur I Tabel 6 kan man se det konceptuelle hierarki mellem hjemmeside, butik og butiks udseende i Magento. Det viser, at der er en overordnet Magento hjemmeside, som kan indeholde flere og forskellige butikker og i dem forskellige butiksudseender eksempelvis ved forskellige landesprog. I forbindelse med denne rapport er der brugt én butik og ét udseende. Alternative butiksudseender er valgt fra, da butikken kun henvender sig til Dansk publikum. Tabel 6 - Figur 1 fra [2] Magento Design guide. Udarbejdet af: Ulrik. Side 9 af 53

15 Pakker og Temaer I Magento har man mulighed for at vælge en temapakke eller et separat tema. Her er hierarkiet som i Tabel 7, hvor man kan have et standardtema med forskellige varianter. I dette projekt arbejdes der med et RWD 9 tema udarbejdet af Magento. RWD blev lanceret med Magento opdatering 1.9. Tabel 7 - Figur 5 fra [2] Magento Design guide. Folder struktur I Tabel 8 kan man se en oversigt over folder-strukturen af et tema. Det er opdelt, således layout holdes adskilt fra design. Layout Skin Tabel 8 - Tema folder oversigt 9 Responsive Web Design Udarbejdet af: Ulrik. Side 10 af 53

16 RWD står for Magentos Responsive Web Design og blev lanceret med Magento version 1.9. Det aktuelle tema er: kalejdoskoprwd og ligger under RWD mappen. Den ligger således i folderen: app/design/frontend/rwd/kalejdoskoprwd. Et tema indeholder tre primære layout foldere: Layout: Indeholder xml filer med layout information, der i blandt blokstruktur til de enkelte sider. Locale: Indeholder sprogfoldere og i dem en csv fil med oversættelser til temaet. Template: Indeholder PHtml og PHP sider nødvendigt for at skabe de endelige sider. Et RWD tema indeholder fire primære skin elementer: CSS: Indeholder CSS filer med information om, hvordan de enkelte elementer på hjemmesiden skal præsenteres. Images: Indeholder billeder tilhørende temaet. JS: Indeholder JavaScript tilhørende temaet. SCSS: Indeholder SCSS filer, SCSS filerne bruges kun under udvikling, hvor slut produktet heraf erstatter indholdet i CSS folderen. Fallback i Magento Magento gør brug af et robust fallback system, som vist i Tabel 9. Udarbejdet af: Ulrik. Side 11 af 53

17 Tabel 9 - Figur 9 fra [2] Magento Design guide. Et tænkt forløb ville være at lede efter en template-fil i det aktuelle tema fra Tabel 8. Her starter man med at lede i tema folderen: app/design/frontend/rwd/kalejdoskoprwd/template. Hvis filen er at finde, bruges denne. Hvis den ikke er at finde, leder man i pakkens default placering, som i dette tilfælde vil være: app/design/frontend/rwd/default/template. Som før hvis filen er fundet kan der begyndes, ellers søges en sidste gang i: app/design/frontend/base/default/template. Hvis filen ikke er tilstede her, returneres søgningen med fejlen, at filen ikke blev fundet på app/design/frontend/base/default/template. Det er vigtigt at notere sig, at fejlen returnere slut stedet, og ikke der hvor man startede søgningen. Da filen typisk vil skulle ligge i temaets folder, så der ikke skal ledes efter filen for ofte. Moduler Magento er modul baseret, det gør det nemt at skræddersy Magento. For Kalejdoskop har vi eksempelvis deaktiveret enkelte nøglefeatures, da de ikke var interessante for kunden samt overskrevet andre for at fremme det rette udtryk. Via Magento Administrations panel kan man deaktivere moduler og via Magentos indbyggede downloader, Magento Connect Manager. Udarbejdet af: Ulrik. Side 12 af 53

18 Man kan via Magentos hjemmeside finde moduler og få deres modul nøgler. Med Magento Connect Manager kan man således installere nye moduler og administrere installerede moduler. Det er en god måde at opdatere og fjerne moduler, da man herved sikre, at få alle filerne fjernet fra sit system. Dokumentation i Magento I Designer s Guide to Magento [2] er en designanvisning for brug af Magento. Her var forventningen at finde en standard måde at dokumentere klasser og filer på. I Magentos filer har jeg fundet et mønster for dokumentation. I Tabel 10 under Notice of License er et eksempel på en reference til en licens aftale der er at finde i starten af hver fil. Sidst i Notice of license er beskrevet hvad kategori, pakke og eventuelt modul filen tilhører. Ud fra de oplysninger er filen relativt let at finde og følge i systemet. Som eksempler er her, hvordan PHP og PHtml filer dokumenteres: For PHP filer, Tabel 10 under For PHP, er et eksempel på dokumentation fra en PHP fil. Dokumentationen og klassenavn reflekterer filens placering i systemet. For metoder er der desuden dokumenteret, hvad metoden gør, og hvilken type der returneres. For PHtml filer, Tabel 10 under For PHtml filer, kan man se hvilke blokke der er brugt til oprettelse af dokumentet og via navngivningen deres placering i systemet. Udarbejdet af: Ulrik. Side 13 af 53

19 Notice of licence For PHP filer: Eksempel placeret i: sti: code/core/mage/catalog/block/product/view.php For PHtml filer: Eksempel placeret i: sti: design/frontend/rwd/kalejdoskoprwd/template/catalog/product/view.phtml Tabel 10 - Magento dokumentations oversigt Ved at have sammenhæng mellem placering i systemet og dokumentation/navngivning, giver det et utroligt godt overblik over systemet, og hvor man skal ændre eller fejlfinde i koden. Magento - MVC - Model View Controller I Magento bruges MVC ikke traditionelt, da view og modellag ikke er adskilte. Det formodes at være på grund af fleksibiliteten af at bruge være et CMS. Udarbejdet af: Ulrik. Side 14 af 53

20 Tabel 11 viser et hændelsesforløb fra en forespørgsel til den endelige visning i Magento. Først kommer der en forespørgsel til systemet. Systemet finder herefter den rette controller til opgaven. Controlleren kan nu manipulere data eller sende forespørgslen videre til view ved at indlæse layout. I view fyldes layout med blokke, som igen fyldes med modeller fra model laget. Herefter bliver præsentations siden oprettet og sendt til brugeren. Tabel 11 - Rajesh's Tech Blog: Magento MVC Architecture fra I forhold til traditionel MVC er controllerne her meget tynde og indeholder kun basal funktionalitet, hvor meget af forretnings logikken er flyttet op i præsentations laget. Det gør at lagene bliver knudret sammen og overblikket let forsvinder. Udarbejdet af: Ulrik. Side 15 af 53

21 Magento ORM Magento bruger en speciel lavet ORM 10 der er basseret på Zend Framework til at oprette og gemme objekter i MySQL. Der er to model typer som arver fra her sin klasse. De er: Simple modeller, der arver fra: Mage_Core_Model_Resource_Db_Abstract. EAV 11 modeller der arver fra: Mage_Eav_Model_Entity_Abstract. Data modeller Data modeller er traditionelle SQL modeller. Der gemmes i statisk tilpassede database tabeller. EAV Model EAV modeller gemmes dynamisk i databasen i en samling af tabeller, hvor der gemmes i flere tabeller. Her er en tænkt gennemgang, eksempel er vist i Tabel 12 ved et simplificeret EAV kunde objekt, der gemmes: 1. Entity tabellen tilskrives objektets id og type id. 2. Attribut tabellen, indeholder en liste af alle attributter der er i systemet. Her findes de attributter objektet indeholder. 3. Value tabellen tilskrives objektets id, attribut id og værdi. Objekt (1) Entity tabel (2) Attribut tabel (3) Value tabel ID: 1 Type_id: 5 Type: Kunde Navn (Nvarchar): Jens Tabel 12 - EAV Tænkt eksempel ID: 1 ID: 10 Nvarchar: Navn ID: 1 Attribut_id: 10 Værdi: Jens EAV er en skalerbar og dynamisk måde at arbejde på, hvor man kan gemme alle slags og sammensætninger af data. Problemerne ved EAV er, at det kræver flere kald i databasen for at samle data igen. I bedste tilfælde skal der søges i tre tabeller, hvorefter data samles, frem for med simple modeller at kunne udføre én søgning. Desuden må det forventes, at søgningerne i EAV bliver langsommere og langsommere, jo flere elementer der er i kolonnerne. 10 Object Relational Mapping 11 Entity Attribute Value Udarbejdet af: Ulrik. Side 16 af 53

22 Debug i Magento Det har været nødvendigt at finde et værktøj til at debugge Magento med, da det hurtigt kan bliver meget komplekst at ændre eller tilføje til Magentos kode. Magento laver logfiler på serveren, hvor der er en log for fejl og en for systembeskeder. Som det fremgår af Tabel 13 - "Magento fejl og system log" får man, ud fra loggen, et klart billede af, hvor og hvornår det er gået galt. Ved fejl loggen får man et billede af stacken, så man kan finde tilbage til det område, hvor fejlen skete. Med system loggen får man i de fleste sager ikke en stack, men derimod den berørte linje og hvad problemet var i linjen. Fejl log: System log: Tabel 13 - "Magento fejl og system log" xdebug i Magento xdebug er en debug udvidelse til PHP. Med xdebug laver man en forbindelse til sit IDE og PHP script. Herved kan man via sit IDE live debugge PHP scriptet. Det har fungeret perfekt efter hensigten, hvor man i IDE tænder for forbindelsen og sætter et break point. Når hjemmesiden når til break point, får man kontrollen i IDE, hvor man kan se de aktive Variabler. Tabel 14 - "Debug af Magento" viser et eksempel over debug af produkt visning, hvor man kan se værdierne for $_product og list af den data, det objekt har på sig. En af ulemperne ved xdebug er, at jeg ikke kan bruge selve metoden som break point, men jeg skal bruge PHP kode snips som break point. Udarbejdet af: Ulrik. Side 17 af 53

23 Tabel 14 - "Debug af Magento" Integration / API Magento har integration til REST og SOAP Api. Da Magento er en open source e-handels platform, er det oplagt at understøtte integrationer til web services. Udarbejdet af: Ulrik. Side 18 af 53

24 Teknologi I projekt perioden har jeg arbejdet i med forskellige teknologier. Jeg vil i dette afsnit beskrive dem. FTP På test og live server har jeg opdateret filerne via en FTP-server. phpmyadmin Ændringer i databasen er foregået via phpmyadmin panel. phpmyadmin er blevet brugt både lokalt og i online miljøerne, hvilket har bidraget til en meget overskuelig proces. Lokal Bitnami VM med Magento Til at arbejde lokalt med Magento, brugte jeg en Virtuel maskine fra Bitnami. Det fungerede som en lukket boks, hvor jeg via interface havde mulighed for at starte og stoppe VM. VM fra Bitnami brugte samme struktur som på live og test serverne jeg brugte. Det var rigtigt godt med samme struktur hele vejen rundt, da jeg på den måde kunne arbejde parallelt. I VM fra Bitnami var en Apache server og en MySQL server. Til håndtering af MySQL var phpmyadmin. Test server Test serveren er en klonet kopi af live site, begge ligger på servere hos udbyderen Powerhosting. Opdateringsproces Under udviklingen har jeg eksperimenteret og udviklet lokalt. Hvorefter jeg har opdateret test serveren, hvor kunden havde mulighed for at kontrollere og godkende de ændringer, jeg havde lavet. Herefter blev live serveren opdateret. Backup Powerhosting laver dagligt backup af live miljø. Backup er tilgængelig via en FTP server. Som vist i Tabel 15 gemmes backup af database og hjemmeside særskilt og i forskellig tid. Database Hjemmeside Daglig backup Op til 31 dage. Op til 7 dage. Månedsbackup Op til 1 år. Op til 1 år. Tabel 15 - Backup lagrings tider Udarbejdet af: Ulrik. Side 19 af 53

25 Det giver god mening at gemme mange kopier af databasen, da den er meget forretningskritisk. Opstår et problem, kan man gå tilbage til et specifikt tidspunkt før dette indtraf. Der foretages ikke nær så mange lagringer af hjemmesiden som af databasen. Det kunne skyldes, at hjemmesidens filer ikke er nær så kritiske og lettere at genskabe, hvis der skulle være problemer. Når en Magento hjemmeside er kørende, vil den største forskel på de forskellige udgaver af backup være billeder i medie mapperne. IDE Et IDE 12 er et udviklings værktøj som kan stå alene og bruges til udviklingen af et program. Typisk en kode editor, kompiler og debugger med et grafisk bruger interface. Atom Tidligt i projektet brugte jeg Atom [3], et open source notesblok program. Med Atom vist i Tabel 16 kan man få et godt overblik over projektet og kode highlighting. Tabel 16 - Brugerflade eksempel fra Atom 12 Integrated Development Environment Udarbejdet af: Ulrik. Side 20 af 53

26 Visual Studio Visual Studio [4], et IDE udviklet af Microsoft og indeholder en integreret versions styring: Team Foundation Server. Visual Studio understøttede ikke PHP og kunne derved ikke bruge det som et IDE i mit projekt. Versionsstyringen kunne bruges separat ved at oprette et hjemmeside projekt i Visual Studio og inkludere projektfilerne. PHPStorm PHPStorm [5], et PHP IDE udviklet af JetBrains. PHPStorm vist i Tabel 17 indeholder utroligt mange features, blandt de vigtigste er: Intelligent kode editor Debugging og test værktøjer Versions styring Tabel 17 - Brugerflade eksempel fra PHPStorm Risici registrering For projektet registrerede og fulgte jeg den samlede risici eksponering af projektet løbende. Jeg havde et Excel ark hvori jeg noterede risiko tekst, sandsynlighed for udfald, størrelsen af tab og risikoens eksponering. Risikoens eksponering er beregnet ved at gange sandsynligheden med tabets størrelse i dage. Derudover lavede jeg også et Risici Burndown diagram, med den samlede risici for hvert sprint. Udarbejdet af: Ulrik. Side 21 af 53

27 Udviklingsmetoder Scrum Scrum er en agil udviklingsmetode, der definere, hvordan et projekt skal styres. Scrum hoved principper: Selv organiserende teams Iterativ udvikling, max 4 uger. Låste krav i aktive sprint. Krav listes i en Product Backlog. Review som afslutning af hver sprint, med interessenter. Scrum begreber og processer Roller Product Owner Product Owner er en kunde repræsentant, og er den primære kontaktperson mellem team og virksomheden. Product Owners opgaver er: Definering af krav/features i Product Backlog. Fastlægger release datoer. Prioritere Product Backlog efter forretnings værdi. Klargør Product Backlog før hver Sprint Planning Meeting. Godkender eller afviser features ved Sprint Review Meeting. Scrum Master Scrum master repræsentere ledelsen i projektet. Scrum master opgaver er: Kommunikationsled mellem Team og Product Owner. Står for kommunikation mellem Team og den ydre verden, så teamet ikke bliver forstyrret. Ansvarlig for team overholder Scrum værdier og praktikker. Styrer teamet ved møder. Fjerner forhindringer for teamet. Er coach for teamets medlemmer, fremmer samarbejde, sikre ressourcer Team Scrum Teamet: Udarbejdet af: Ulrik. Side 22 af 53

28 Har en ideel størrelse på 7-9 personer. Ingen faste roller eller opgaver, alle gør alting. o Eks. analysere, design, programmer, test, estimering, planlægning, opfølgning. Arbejder fuld tid i teamet. Er selvorganiserende, finder internet ud af hvordan de vil arbejde. Er låst til projektet i perioden, der er derved ikke tilladt udskiftninger af medarbejdere i en sprint periode. Artefakter Product Backlog Product Backlog er en to-do liste af alle kundens krav, som eksisterer hele projektets levetid. Product Owner har ansvaret for prioritering og vedligeholdelse af Product Backlog. De højst prioriterede elementer i Product Backlog estimeres og beskrives mere detaljeret end lavt prioriterede elementer. Detaljegraden af elementer i Product Backlog kan variere fra en overskrift til en Story eller Use Cases. Sprint Backlog Sprint Backlog er en udvalgt liste af opgaver, der skal udføres i det angivne sprint og eksistere kun i det aktive sprints levetid. Sprint Backlog laves i samarbejde mellem Team og Product Owner ved Sprint Planning Meeting, og er her herefter låst resten af sprintet. Sprint Backlog fyldes ved Sprint Planning Meeting med de højst prioriterede elementer i Product Backlog. Elementer fra Product Backlog kan opdeles i mindre bidder for bedre at kunne blive estimeret og tilføjet til Sprint Backlog. Burndown Burndown bruges til at illustrere fremdriften i det aktuelle sprint. Grafen summerer de tilbageværende arbejdsopgavers værdi i forhold til det antal resterende dage i sprintet, gange med teamets velocity. Burndown opdateres hver dag, og grafen indikere om teamet har for meget/lidt arbejde tilbage til den resterende del af sprintet. Burndown skal være synligt for alle teamets medlemmer og eksistere kun i det aktive sprints levetid. Teamets velocity angives som det samlede antal story point, teamet kan lave på en given dag. Udarbejdet af: Ulrik. Side 23 af 53

29 Ceremonier Sprint Planning Meeting Før Sprint Planning Meeting har Product Owner fået re-prioriteret Product Backlog, så de aktuelt forretnings vigtigste er top prioriteret. Sprint Planning Meeting afholdes før starten af hvert sprint. Her fastlægges mål for sprintet, planlægning af sprintet og overordnet design overvejelser i forbindelse med udvalgte opgaver. Team og Product Owner beslutter i samarbejde hvad der skal med i næste sprint, ud fra Return of Investment for kunden. De diskutere indholdet af de højst prioriterede elementer og efter behov opdeler disse i mindre bidder. Herefter estimeres de, eventuelt med planning poker. Hvorefter de højst prioriterede elementer udvælges og tilføjes til Sprint Backlog. Standup Meeting Standup Meeting er et kort dagligt møde teamet holder internt. Mødet holdes stående for at sikre et kort og engageret møde. Til Standup Meeting vil det være oplagt at opdatere Burndown, så man har den at forholde sig til i forhold til status. Målet er at alle får svaret på følgende: Hvad har vi lavet siden i går? Hvad skal der laves i dag? Er der forhindringer? Ved Standup Meeting skal alle teamets medlemmer på tur give status og det er ikke tilladt at diskutere men informere. Herefter er det Scrum Masters opgave at tage sig af eventuelle problemer. Sprint Review Efter endt sprint, afholdes Sprint Review. Her deltager Team, Product Owner og interessenter. Team præsentere det de har lavet i sprint og fået det vurderet af Product Owner. Product Owner vurdere hvad der: Var godt eller mindre godt? Skal tilbage til Product Backlog? Sprint Retrospektive Sprint Retrospektive er et internt møde for Team hvor sprintet evalueres: Udarbejdet af: Ulrik. Side 24 af 53

30 Hvad gik godt? Hvad kunne have været bedre? Hvad overraskede os? Med Sprint Retrospektive er målet af Teamet konstant udvikler sig til at blive bedre. Scrum begreber og proces forløb I Tabel 18 kan man se et traditionelt forløb med Scrum: 1. Product Owner indsamler og lister ønskede features i Prioriteret Product Backlog. 2. Product Owner og Team laver ved Sprint Planning Meeting en Sprint Backlog. 3. Team udfører sprint med daglige Standup Meetings. 4. Product Owner og Team udfører Sprint Review. 5. Team udfører Sprint Retrospektive. 6. Herefter gentages punkterne 1-5 til projektet er færdigt. Tabel 18 - Scrum begreber og proces, fra [6] Agile Methods Of Software Development Udarbejdet af: Ulrik. Side 25 af 53

31 Scrum Buts Scrum fungere som en helhed, hvor elementerne supplere hinanden. Det er derfor vigtigt for at kunne se konsekvenserne ved at fjerne elementer fra Scrum at notere hvordan og hvorfor man ikke overholder Scrum. Eks. Vi bruger Scrum, men Standup Meeting hver dag udføres ikke, da det tager for lang tid. Men vi laver det hver mandag. Solo Scrum Scrum er designet med fokus på teams, hvor den optimale størrelse er af 7-9 personer. Da jeg laver dette projekt alene valgte jeg at undersøge om der på nettet var eksempler for implementering af Scrum alene. Jeg fandt en interessant artikel [7] Solo Scrum hvor forfatteren arbejdede helt alene på et internt projekt og brugte Scrum. Artiklen var særligt interessant da der er mange konstruktive kommentarer der føre til en debat om brug af Scrum alene. I artiklen forklare han hvordan han i projektet havde alle projekt rollerne, og skiftede mellem dem efter behov og herved kunne anskue projektet forskelligt efter hvilken rolle han udfyldte. Han beskrev ikke hvordan eller om han udføre Standup Meeting eller Review. Men om brugen af Standup Meetings alene argumenterede han for at formålet var at give teamet et samlet overblik over processen. Hvorved enkelt personer ville have lettere ved selv at gennemgå og se deres status. Den samme vurdering af retrospekt, hvor en enkelt person burde være i stand til at vurdere og perspektivere over processen. Han havde også arbejdsopgaver ved siden af projektet i hans sprint. Hvor han både solgte og ydede support. Ud fra artiklen virker det meget rodet at have Product Owner og Team rollerne blandet sammen, det vil jeg for alt i verden undgå. Det kan også være et kæmpe problem hvis man ikke har 100% fokusere på opgaven i sprint perioderne, så kan deadlines og hele projektet hurtigt flyde ud i sandet, specielt når han som i artiklen selv står for alle Scrum rollerne. En udfordring ved at være alene i Scrum team, må være at få reflekteret over processen. Til det forestiller jeg mig at skrive noter for de enkelte dage og herefter at skrive refleksionerne ned ud fra dem. Målet med noterne er at sikre der er et starts indhold til retrospektiv og ved at genlæse noten kunne det føre til en ny refleksion. Alt i alt virker det til Scrum kan fungere som enkelt person. Dog ser jeg det som et krav at Product Owner og Team holdes afskilt. Udarbejdet af: Ulrik. Side 26 af 53

32 XP 13 XP er en agil udviklingsmetode, der definere hvordan der skal arbejdes i projektet, via en række praktikker. Grund ideen bag XP er at man skal tage den sunde fornuft til ekstremerne og samtidig opnå en god kvalitet for kunden og af koden. XP bruger Praktikker og Værdier til at definere hvordan der skal arbejdes med XP. Det er vigtigt for at få det fulde udbytte af XP at alle praktikker og værdier overholdes. XP Praktikker XP har en række praktikker som når de bruges samlet i et projekt, hjælper med til at opretholde en vis kvalitet af arbejdet. Praktikkerne er i Tabel 19. XP Praktikker Par programmering 2 udviklere, 1 tastatur. Planning Game Team og Kunde estimere opgavers værdi. Test først udvikling Der laves test først og herefter kodes til testen opfyldes. Kundeinvolvering Kunden stiller og definere kravene løbende. Løbende integration Dagligt kompilering og integrering. Refaktorering Koden forbedres løbende. Små udgivelser Små releases. Kodestandard Kodestandard. Kollektivt ejerskab Enhver i teamet har overblik og kan ændre hvad som helst. Simpelt design Koden dækker kun de opstillede krav. Metafor Fælles terminologi og begreber. 37 timers arbejdsuge Fokuserede medarbejdere, mindsker fejl. Tabel 19 - XP Praktikker XP Værdier XP værdier er i Tabel 20. XP Værdier Forenkling Kommunikation Mod Tilbagemelding Tabel 20 - XP Værdier 13 extreme Programmering Udarbejdet af: Ulrik. Side 27 af 53

33 Solo XP Jeg fandt en diskussions tråd [8] Extreme Programming For One med et tænkt eksempel, om en Solo udvikler kunne få udbytte af at bruge XP. I diskussionen konkluderes at han godt kunne bruge XP. Men at han som kompensation for at ikke kunne udføre par programmering, skulle opføre sig som en partner og revurdere koden. Eller ved tilfældige intervaller stille sig selv spørgsmålene: Hvor længe er det siden du sidst har tjekket ind? Du har tænkt dig at optimere det her, ikke? Er det den mest optimale måde at lave det på? Har du lavet en testet til dette? Jeg vurderede at XP praktikkerne ville være gavnlige som supplement til Scrum i et en mands projekt. Dog med forbehold om at være ekstra kritisk til egen kode. Projekt Metode valg I dette projekt valgte jeg at arbejde agilt frem for plandrevet. Valget er truffet på en agil udviklings metode da: Kunden ikke har fast definerede krav for projektet. Arbejdsopgavernes kompleksitet har ikke været høj og med et lille team har det ikke været nødvendigt med meget dokumentation. Med kundeinvolvering kan kunden vurdere og komme med ændringer til produktet i forløbet. Valget er faldet på Scrum og XP praktikker. Jeg har tidligere arbejdet på den måde i hold af 4 personer. Udfordringen denne gang er at være alene om projektet, hvor Scrum og XP praktikker er designet til hold. Jeg har valgt at finde eksempler for implementering af Scrum og XP i en mands hold. I det følgende beskrives hvordan Scrum og XP praktikker implementeres i projektet. Implementering af Scrum I projektet er jeg både Scrum Master og Team. Product Owner er Sofie, en fast kontakt person hos Kalejdoskop. Som Sprint Board vil jeg bruge Trello.com med Scrum for Trello plugin og layout fra Tabel 21 til Scrum Board. Med Scrum Board får jeg et godt overblik over opgaverne og status i det aktuelle sprint. Plugin giver muligheden for at se Burndown i sprintet. Udarbejdet af: Ulrik. Side 28 af 53

34 Product Backlog Sprint Afsluttede Sprint X Product Backlog Story To Do In Progress To Verify Done Afsluttede Sprint X Tabel 21 - Scrum board i Trello Hver tirsdag er planen sammen med Product Owner at udføre: Sprint Review og Sprint Planning. Product Owner er ikke i stand til at estimere opgavers værdi, så ved Sprint Planning har jeg estimeret de top prioriterede opgaver i Product Backlog hvorefter Product Owner har sorteret og udvalgt opgaver til sprint fra Product Backlog. Herefter vil jeg udføre Sprint Retrospektive og bruge de skrevne noter som udgangspunkt. Scrum But Projekt Sprint Backlog er i projektet låst i det omfang at Product Owner ikke mens Sprintet er aktivt kan ændre dets indhold eller mål. Men Scrum Master og Team kan tilføje uventede opgaver så længe det ikke influere sprintets mål. Implementering af XP praktikker I projektet vil jeg bruge XP praktikker til at understøtte Scrum. I Tabel 22 er en vurdering af hvordan XP praktikkerne kan implementeres ud fra overvejelser om Solo XP. XP Praktikker implementeret i Scrum projekt Løbende integration Efter hver dag opdateres test serveren med de nyeste ændringer. Herved kan ændringerne testes før de lanceres på live serveren. Refaktorering Koden forbedres løbende. Der oprettes TODO tags i koden når den er skrevet, med en beskrivelse af hvordan koden kan optimeres. Kodestandard Ved ændring eller udarbejdelse af kode vurderes kodestandarden i den eksisterende først hvorefter koden skrives. Kollektivt ejerskab Teamet skal have ejerskab over koden og ved større ændringer eller implementering af kode skrives kommentarer, så fremtidige brugere kan få overblik over koden. Simpelt design Koden skal kun dække de opstillede krav. Metafor Fælles terminologi og begreber. 8 timers arbejdsdag For at få struktur på dagene har jeg valgt en fast arbejdsdag af 8 timer. Test først udvikling Der skal om muligt laves tests for arbejdsopgaver. Implementeret via Scrum Små udgivelser Der arbejdes i 1 uges Scrum sprint, ved de korte sprint kan Udarbejdet af: Ulrik. Side 29 af 53

35 Kundeinvolvering Kunden involveres som Product Owner i projektet. Hvor kunden løbende definere krav. Planning Game Kunden har ikke erfaring med estimering af arbejdsopgaver, derfor estimeres og vurderes opgaverne af Scrum team. Undladt implementeret Par programmering Der forsøges at kompensere for Par programmering ved ekstra kritisk at forholde sig til kvaliteten af koden. Ved at agere partner efter koden er skrevet. Tabel 22 - XP Praktikker Produkt Backlog I Tabel 23 er Product Backlog fra projekt forløbet. Listen er sorteret i den rækkefølge opgaverne er blevet udført. Opgaver markeret med fed er tilføjet til den oprindelige Product Backlog. ID Type Værdi Title Løst i 1 Spike 8 Opsætte udviklings miljø Sprint 0 2 Task 8 Projekt struktur Sprint 0 3 Spike 8 Forside Sprint 0 4 Story 2 Cookie warning Sprint 1 5 Task 0,5 Banner Fjern eksisterende Sprint 1 6 Story 1 Menu Sprint 1 7 Task 2 Ændre sprog til dansk Sprint 1 8 Task 0,5 Opdatere footer så den er responsiv/mobilvenlig Sprint 1 9 Task 1 Fjern ubrugte moduler Sprint 1 10 Task 2 Opdater moduler til nyeste version Sprint 1 38 Task 2 Akut Aktiver Cron mail forsendelse Sprint 1 39 Task 3 Magento Undersøg Cron mail Sender ikke konsistent Sprint 1 11 Story 3 Blog Sprint 2 12 Task 5 Finde og rette fejl på kategori side Sprint 2 13 Task 5 Tilpasse kategori side så den er responsiv Sprint 2 14 Task 3 Tilpasse produkt side design Sprint 2 15 Task 2 Tilpasse produkt side så den er responsiv Sprint 2 16 Story 5 Filtrering af brands Sprint 2 Udarbejdet af: Ulrik. Side 30 af 53

36 17 Task 5 Filtrering af flere brands Sprint 2 18 Spike 8 Undersøg udnyttelse af klient-cache Sprint 2 40 Task 0,5 Opret produkt egenskab materiale Sprint 3 41 Task 1 Opdatere blog linje afstand Sprint 3 42 Task 1 Opdatere blog kategorier Sprint 3 43 Task 0,5 Opdatere frontend navngivning af produkt beskrivelser, lang og kort Sprint 3 44 Task 2 Ændre produkt beskrivelser, lang og kort. Så de bruger samme formatering Sprint 3 45 Spike 8 Skift udviklings miljø til PHPStorm Sprint 3 46 Spike 8 Tilpasse filtrering af kategorier så rod kategorier for valgt kategori altid er Sprint 3 tilgængelige 47 Story 20 Filtrering Sprint 4 48 Task 8 Ad hoc ændringer for at opfylde E-mærke Sprint 4 49 Task 5 Tilføje harmonika foldning til filtrerings underkategorier Sprint 5 50 Task 3 Forhindre at filtrering pakkes ud når den er aktiv Sprint 5 51 Task 3 Automatisk udfoldning af aktiv kategori Sprint 5 19 Task 5 Tilpas produkt side, så billede tekst bliver vist Sprint 5 20 Task 5 Tilpas produkt side, så korrekte billeder bliver vist, nu er det et hovedbillede for Sprint 5 meget 21 Task 3 Tilpasse standard sider, så body passer i nyt tema Sprint 5 52 Task 8 Møde med Ipos angående skift til deres system Sprint 6 53 Task 2 Forside styling(: Center) af nyhedsbrev Sprint 6 22 Spike 8 Undersøg forskellige forside alternativer Sprint 6 23 Task 5 Opret og implementer venstre side banner 24 Task 8 Tilpasse banner til tema 25 Task 8 Undersøg og implementer popup, via Banner Slider 26 Task 5 Flyt indretning fra en CMS side til en WordPress blog 27 Task 8 Tilpas side banner, så de følger siden når der scrolles 28 Task 2 Tilpas quick søgnings vindue, så popup vinduet hænger sammen med indtastningsvinduet 29 Spike 8 Undersøg og udnyt Robots.txt Udarbejdet af: Ulrik. Side 31 af 53

37 30 Story 20 Billede skift på produkt side 31 Spike 8 Undersøg og løs hvorfor cache konstant skal fornyes 32 Task 8 Menu elementer skal sorteres lodret, frem for vandret (Billede) 33 Task 8 Bruger indtastet værdi Gavekort 34 Spike 8 Auto skaller billeder til device via JS 35 Task 8 Tilpas menu placering ved åbning 36 Task 1 Ændre hvordan footer folder responsivt 37 Task 5 Guide til oprettelse af produkter 49 Spike 8 Undersøg muligheden for TDD af Magento 55 Task 5 Flere valg, ikke synlig ved søgning Tabel 23 - Produkt Backlog for projekt Udarbejdet af: Ulrik. Side 32 af 53

38 Sprint Sprint 0 Sprint planning Sprint 0 brugte jeg til at få sat opsat udviklings miljø og testet spikes. Sprint Backlog for Sprint 0 er vist nedenfor i Tabel 24: ID Type Værdi Title Løst i 1 Spike 8 Opsætte udviklings miljø Sprint 0 2 Task 8 Projekt struktur Sprint 0 3 Spike 8 Forside Sprint 0 Tabel 24 - Sprint 0 Sprint Backlog Retrospektive Burndown Burndown for Sprint 0 er vist i Tabel ,0 25,0 20,0 15,0 10,0 5,0 Burndown Sprint 0 0, Start Slut Start Slut Start Slut Dag 1 Dag 2 Dag 3 Burndown Sprint 0 (21-04 <> 28-04) Ideel Tabel 25 - Sprint 0 Burndown I løbet af sprint 0 fik jeg afsluttet alle de udvalgte emner fra Sprint Backlog i Tabel 24. Fra Burndown vist i Tabel 25 kan man se at det aktuelle og ideelle estimerede forbrug stemmer overens. Af det kan man lede at indholdet i Sprint Backlog har været estimeret korrekt. Udarbejdet af: Ulrik. Side 33 af 53

39 Hvad gik godt? Tidsplanen holdt Hvad kunne have været bedre? I løbet af sprint oprettede jeg 3 risiko opgaver, i Tabel 39 med ID 1-3. Hvad overraskede? Ikke noget at nævne. Sprint 1 Sprint planning I sprint 1 startede jeg for alvor på projektet. Her startede jeg ud sammen med Produkt Owner at udvælge de højest prioriterede opgaver fra Product Backlog som skulle med i Sprint Backlog. Sprint Backlog er vist i Tabel 26. ID Type Værdi Title Løst i 4 Story 2 Cookie warning Sprint 1 5 Task 0,5 Banner Fjern eksisterende Sprint 1 6 Story 1 Menu Sprint 1 7 Task 2 Ændre sprog til dansk Sprint 1 8 Task 0,5 Opdatere footer så den er responsiv/mobilvenlig Sprint 1 9 Task 1 Fjern ubrugte moduler Sprint 1 10 Task 2 Opdater moduler til nyeste version Sprint 1 18 Spike 8 Undersøg udnyttelse af klient-cache Sprint 2 24 Task 8 Tilpasse banner til tema 38 Task 2 Akut Aktiver Cron mail forsendelse Sprint 1 39 Task 3 Magento Undersøg Cron mail Sender ikke konsistent Sprint 1 Tabel 26 - Sprint 1 Sprint Backlog I Tabel 26 blev de to opgaverne med ID: 38 og 39 tilføjet mens sprintet var i gang. Review I sprintet løb jeg ind i en række akutte problemer, efter jeg opdaterede Magento fra version til I første omgang havde jeg udført opdateringen på mit lokale og på Test-serveren uden problemer. Da jeg Udarbejdet af: Ulrik. Side 34 af 53

40 opdaterede Live-serveren, resulterede det i en http fejl 500 HTTP Error 500 Intern server fejl. Det viste sig at være et problem med tilladelserne for index.php, hvor filen udsatte systemet for en sikkerhedsrisiko. Dag 3 præsenterede et nyt akut problem sig, ved at Live-serveren ikke længere sendte salgs mails ud. Til at løse dette oprettede jeg en opgave med ID 38 i Sprint Backlog. Efter Cron igen kom til at virke dukkede et nyt problem op, hvor enkelte mails ikke blev afsendt. Til at løse dette oprettede jeg en opgave med ID 39 i Sprint Backlog. Retrospektive Burndown Burndown for Sprint 1 er vist i Tabel ,0 25,0 20,0 15,0 10,0 5,0 Burndown Sprint 1 0, Start Slut Start Slut Start Slut Dag 1 Dag 2 Dag 3 Burndown Sprint 1 (28-04 <> 05-05) Ideel Tabel 27 - Sprint 1 Burndown Problemerne i sprint 1 resulterede i at jeg sidst på anden dagen fjernede opgave 18 af 8 point, da jeg var kommet for langt bag ud i forhold til tidsplanen. På dag 3 tilføjede jeg fra morgenstunden opgaverne 38 og 39. Sidst på dag 3 fjernede jeg opgave 24 da jeg ikke kunne nå den. Hvad gik godt? Det har fungeret godt med en fast ugentlig dag til Review, Retrospektive og Sprint Planning. Hvor der rigtigt er tid til at fokusere på processen. Udarbejdet af: Ulrik. Side 35 af 53

41 Hvad kunne have været bedre? Ved opdateringer vil jeg frem ad rettet afsætte markant mere tid til det, og bruge mere tid på at teste at det virker. Særligt med henblik på test af mail og betaling, som kun kan testes på Live serveren. I løbet af sprint oprettede jeg en risiko opgave i Tabel 39, med ID 4. Da der kunne være flere foldere og filer med forkert tilladelser på serveren. Hvad overraskede? Det overraskede at jeg havde brugt så meget tid problemer i forbindelse med opdateringen og de medfølgende problemer. Sprint 2 Sprint planning Sprint Backlog for sprint 2 er vist i Tabel 28: ID Type Værdi Title Løst i 11 Story 3 Blog Sprint 2 12 Task 5 Finde og rette fejl på kategori side Sprint 2 13 Task 5 Tilpasse kategori side så den er responsiv Sprint 2 14 Task 3 Tilpasse produkt side design Sprint 2 15 Task 2 Tilpasse produkt side så den er responsiv Sprint 2 16 Story 5 Filtrering af brands Sprint 2 17 Task 5 Filtrering af flere brands Sprint 2 18 Spike 8 Undersøg udnyttelse af klient-cache Sprint 2 Tabel 28 - Sprint 2 Sprint Backlog Review Sprintet forløb som planlagt, dog var opgaverne 16 og 17 noget mere komplekse end først antaget. Udarbejdet af: Ulrik. Side 36 af 53

42 Retrospektive Burndown Burndown Sprint 2 40,0 35,0 30,0 25,0 20,0 15,0 10,0 5,0 0, Start Slut Start Slut Start Slut Start Slut Dag 1 Dag 2 Dag 3 Dag 4 Burndown Sprint 2 (05-05 <> 12-05) Ideel Tabel 29 - Sprint 2 Burndown Sprintet forløb efter planen for de første to dage. Efter dag 3 kunne jeg se jeg var ved at komme bag ud, men havde en forventning om at jeg ville indhente det på 4. dagen. På dag 4 nåede jeg at indhente det, så alle opgaverne blev afsluttet. Hvad gik godt? Jeg har i sprint 2 fået en bedre forståelse for Magentos opbygning og struktur. Hvad kunne have været bedre? Underestimering af opgaver er stadig et problem. Hvad overraskede? Ikke noget at nævne. Udarbejdet af: Ulrik. Side 37 af 53

43 Sprint 3 Sprint planning ID Type Værdi Title Løst i 40 Task 0,5 Opret produkt egenskab materiale Sprint 3 41 Task 1 Opdatere blog linje afstand Sprint 3 42 Task 1 Opdatere blog kategorier Sprint 3 43 Task 0,5 Opdatere frontend navngivning af produkt beskrivelser, lang og kort Sprint 3 44 Task 2 Ændre produkt beskrivelser, lang og kort. Så de bruger samme formatering Sprint 3 45 Spike 8 Skift udviklings miljø til PHPStorm Sprint 3 46 Spike 8 Tilpasse filtrering af kategorier så rod kategorier for valgt kategori altid er tilgængelige Sprint 3 Tabel 30 - Sprint 3 planning Review I sprint 3 skiftede jeg udviklings miljø til PHPStorm. Nu var det på tide at komme dybere ned i Magento, efter at have arbejdet i overfladen med at lave design og layout. Indtil nu havde jeg brugt en notepad: Atom og Visual Studio. Med skift til et IDE forventes at kunne håndtere mere komplekse opgaver. Efter skiftet til PHPStorm har det har været interessant at arbejde med et komplekst emne som filtrering. Hvor jeg har kunnet gå i dybden med filtrerings eksperiment. Ved møde med kunden fik vi design på plads for hvordan de ønskede filtrering designet. I det følgende sprint skulle jeg fortsætte udviklingen på eksperimentet. Til arbejdet med filtrering lavede jeg en skitseret Domæne model over filtrering (se Tabel 31) for at få et bedre overblik, det gav et godt overblik over situationen og hvor lidt der skulle ændres for at opnå det ønskede. Tabel 31 - Domæne model filtrering Udarbejdet af: Ulrik. Side 38 af 53

44 Retrospektive Burndown Burndown Sprint 3 30,0 25,0 20,0 15,0 10,0 5,0 0, Start Slut Start Slut Start Slut Dag 1 Dag 2 Dag 3 Burndown Sprint 3 (12-05 <> 19-05) Ideel Tabel 32 - Sprint 3 Burndown Sprintet forløb som planlagt. Hvad gik godt? Efter sprint 3 har jeg fået en endnu bedre platform at arbejde PHP med. Hvor jeg nu er i stand til at debugge PHP koden og objekter. Herved forventer jeg at kunne arbejde med mere komplekse emner og mere effektivt. Estimeringen af opgaverne passede godt i sprintet. Hvad kunne have været bedre? Ikke noget at nævne. Hvad overraskede? Det overraskede at jeg havde brugt så meget tid problemer i forbindelse med opdateringen og de medfølgende problemer. Udarbejdet af: Ulrik. Side 39 af 53

45 Sprint 4 Sprint planning ID Type Værdi Title Løst i 47 Story 20 Filtrering Sprint 4 48 Task 8 Ad hoc ændringer for at opfylde E-mærke Sprint 4 Tabel 33 - Sprint 4 planning Retrospektive Burndown 30,0 25,0 20,0 15,0 10,0 5,0 Burndown Sprint 4 0, Start Slut Start Slut Start Slut Dag 1 Dag 2 Dag 3 Burndown Sprint 4 (19-05 <> 26-05) Ideel Tabel 34 - Sprint 4 Burndown Sprintet forløb som planlagt. Hvad gik godt? Estimeringen af opgaverne passede godt i sprintet. Med PHPStorm var jeg i stand til at få et godt overblik over problemet og i den forbindelse finde og bruge eksisterende kode til filtrering. Hvad kunne have været bedre? Efter at have skiftet IDE fandt jeg ud af at det er muligt at lave tests, men jeg har ikke fået eksperimenteret med det. Jeg har fundet at der traditionelt ikke udføres tests af Magento, hvorved der ikke er så meget information om det. Derfor har jeg valgt at oprette opgave 49 som en spike i Product Backlog. Udarbejdet af: Ulrik. Side 40 af 53

46 Hvad overraskede? Ikke noget at nævne. Sprint 5 Sprint planning ID Type Værdi Title Løst i 50 Task 5 Tilføje harmonika foldning til filtrerings underkategorier Sprint 5 51 Task 3 Forhindre at filtrering pakkes ud når den er aktiv Sprint 5 52 Task 3 Automatisk udfoldning af aktiv kategori Sprint 5 19 Task 5 Tilpas produkt side, så billede tekst bliver vist Sprint 5 20 Task 5 Tilpas produkt side, så korrekte billeder bliver vist Sprint 5 21 Task 3 Tilpasse standard sider, så body passer i nyt tema Sprint 5 Tabel 35 - Sprint 5 planning Retrospektive Burndown 30,0 25,0 20,0 15,0 10,0 5,0 Burndown Sprint 5 0, Start Slut Start Slut Start Slut Dag 1 Dag 2 Dag 3 Burndown Sprint 5 (26-05 <> 02-06) Ideel Tabel 36 - Sprint 5 Burndown Sprintet forløb som planlagt. Hvad gik godt? Estimeringen af opgaverne passede godt i sprintet. Udarbejdet af: Ulrik. Side 41 af 53

47 Hvad kunne have været bedre? Ikke noget at nævne. Hvad overraskede? Jeg har tidligere forsøgt at ændre produkt siderne, så der blev vist det korrekte antal billeder, men fandt ikke en løsning. Denne gang var det meget nemt og overskueligt. Med brug af PHPStorm til at debugge, men selvfølgeligt har jeg også lært mere om Magento siden jeg forsøgte sidst. Sprint 6 Sprint planning ID Type Værdi Title Løst i 53 Task 8 Møde med Ipos angående skift til deres system Sprint 6 54 Task 2 Forside styling(: Center) af nyhedsbrev Sprint 6 22 Spike 8 Undersøg forskellige forside alternativer Sprint 6 Tabel 37 - Sprint 6 planning Review Dag 2 undersøgte jeg hvad alternativer der var til den eksisterende forside. Problemet var at forsiden var for svær at vedligeholde for butikkens ansatte. Løsningen blev et responsivt net, hvor de kunne skifte tekst og billeder via Magentos interface. Løsningen blev implementeret i butikken med det samme. Udarbejdet af: Ulrik. Side 42 af 53

48 Retrospektive Burndown Burndown Sprint 6 20,0 18,0 16,0 14,0 12,0 10,0 8,0 6,0 4,0 2,0 0, Start Slut Start Slut Dag 1 Dag 2 Burndown Sprint 6 (02-06 <> 09-06) Ideel Tabel 38 - Sprint 6 Burndown Sprintet forløb som planlagt. Hvad gik godt? Estimeringen af opgaverne passede godt i sprintet. Spike kunne bruges som den var, som butikkens nye forside. Hvad kunne have været bedre? Ikke noget at nævne. Hvad overraskede? Ikke noget at nævne. Udarbejdet af: Ulrik. Side 43 af 53

49 Samlet risici vurdering En samlet liste af fundne risici er vist i Tabel 39. ID Beskrivelse af risiko Sprint Sandsynlighed Tabs størrelse Eksponering Opdaget Afsluttet (i dage) 1 MySQL - Datatab ved opdatering af 0 20% 1,0 dage 0,20 data via phpmyadmin 2 Manglende Test - Ingen test ved % 2,0 dage 1,00 ændring af kode 3 Fejl i forbindelse med opdatering 1 25% 0,5 dage 0,13 4 FTP - Fejlagtig ændring af filers % 1,0 dage 0,40 tilladelse 5 Skift af IDE har nedskrevet 3 20% 1,0 dage 0,20 sandsynligheden for forekomst af Risiko 3 Tabel 39 - Risici diagram Ud fra Tabel 40 kan man se udviklingen af risici i projekt perioden. Målet med Risici registrering er tidligt at finde og fjerne risici, før de bliver til store problemer. I projektet startede jeg med at finde nogle risici og efterfølgende fjernede eller nedsatte deres eksponering. Risici Burndow 2 1,8 1,6 1,4 1,2 1 0,8 0,6 0,4 0, Risici Tabel 40 - Risici Burndown Udarbejdet af: Ulrik. Side 44 af 53

50 Samlet perspektivering I dette afsnit har jeg udført en samlet perspektivering af projekt forløbet. Magento Da jeg startede på projektet, var Magento en ny teknologi for mig. I forhold til at få og kunne navigere i Magento, har det hjulpet rigtig meget at kigge på de bagvedliggende mekanismer så som PHP og strukturen af Magento. Herudfra har jeg fået et godt overblik over, hvad der sker hvor og hvornår. Efter projektet føler jeg mig rustet til at kunne udvikle og modifere Magento. Scrum Brugen af Scrum i projektet har fungeret rigtigt godt. Det har givet projektarbejdet en god struktur. Estimering af arbejdsopgavernes omfang og værdi er i løbet af projektet blevet bedre og bedre. Roller Det har fungeret overraskende godt med en rigtig kunde tilknyttet projektet til at spare med. Specielt da kundens behov ændrede sig i løbet af projekt perioden. Det har ikke været noget problem både at repræsentere Scrum Master og Team, med adskillelsen af Product Owner ser jeg som essentiel. Ceremonier Sprint Review med kunden har givet meget mere konstruktive feedback, end jeg havde forventet. Noterne jeg lavede til Sprint Retrospekt var utroligt givende. Jeg brugte dem som en dagsorden for Retrospekt. Ved Retrospekt har jeg manglet nogen at spare med i forhold til projektet, det har til tider været svært at se tingene fra mere end én side. Artefakter Under projektet var Sprint Board eller Burndown ikke synligt i lokalet, det var ikke nødvendigt, da jeg arbejdede alene og altid følte, jeg havde overblikket. Men hvis der havde været bare 1 mere i projektet ville det være nødvendigt at have dem synligt i lokalet. XP Praktikker Implementeringen af XP Praktikker har fungeret rigtigt godt som suppleret til Scrum. I det følgende beskrives hvordan Udarbejdet af: Ulrik. Side 45 af 53

51 Løbende integration Jeg har løbende opdateret test serveren og herefter live serveren med testet kode. Når der har været tale om design ændringer, har jeg skubbet ændringen ud hurtigt, da der ikke har været behov for så meget test. Refaktorering Det har været rigtigt godt at lave en markering, hvis den skrevne kode kunne gøres smartere med et TODO tag, for så at kunne finde tilbage til koden og optimere den. Kodestandard Det har ikke været muligt at finde en kodestandard for Magento, men jeg brugt meget tid på at finde eksempler i Magentos filer, når jeg skulle ændre i koden. Det var let at finde lignende scenarier og eksempler at reproducere. Det har fungeret godt, og jeg synes selv, at den kode jeg har formået at lave, går godt i med den eksisterende kode fra Magento. Test først udvikling Det har ikke været muligt at lave test først udvikling endnu, men det er på min TODO liste over fremtiden af projektet, da behovet for test bliver større og større i takt med opgavernes stigende kompleksitet. Udarbejdet af: Ulrik. Side 46 af 53

52 Videre udvikling Efter projektets afslutning er der stadig mange opgaver tilbage i Product Backlog, og stadig flere der ikke er kommet i Product Backlog. Erfaringerne med brug af Scrum og det tætte forhold til kunden har inspireret mig til at starte egen virksomhed. Min plan er at fortsætte samarbejdet med kunden hen over sommerferien, men som selvstændig konsulent. Et af mine mål for arbejdet med Magento er at lave egne moduler i første omgang specifikt til butikken, men på sigt via Magento Connect hvor andre kan få glæde af dem. De er ved at udvikle Magento 2 som næste skridt for Magento. Den er fortsat under udvikling og er i øjeblikket tilgængelig på GitHub til udviklere, men forventes frigivet sidst på året til forretnings brug. Magento 2 Magento 2 indeholder rigtigt mange ændringer i forhold til Magento 1.x, hvoraf nogle af de vigtigste er: Fleksibel arkitektur, endnu mere fleksibel modul struktur. 100% Test venlig, med indbygget test miljø. Her er mulighed for Unit test og mange andre. Ændret folder struktur, så strukturen bliver mere simpel og overskuelig. Lettere at installere. Optimeret skalerbarhed, blandt andet ved fuldsides cache. Mere information til udviklerne. Forbedret sikkerhed. Magento 2 virker rigtigt interessant som udvikler, da der nu er fokus på dokumentation, simplificering og ikke mindst test. Udarbejdet af: Ulrik. Side 47 af 53

53 Konklusion Da jeg startede på projektet, var Magento en ny teknologi for mig. Jeg har formået at lære at arbejde med Magento ved at sætte mig ind i de bagvedliggende mekanismer så som PHP og selve folder strukturen. Dette har givet mig grundlæggende viden og kompetencer i forhold til at arbejde med Magento, og hvordan Magento er opbygget. I løbet af projektet har jeg løbende ændret Magentos design og layout efter kundens behov. Desuden har jeg tilføjet en ny funktionalitet til Magento ved at tilpasse filtrering efter kundens behov, hvorved jeg har opfyldt mine mål om at være i stand til at tilpasse Magento design og layout samt udbygge Magento med ny funktionalitet. Processen med at arbejde alene og bruge Scrum og XP praktikker har fungeret rigtigt godt og effektivt. Det har særligt været godt med en virkelig kunde at stå til regnskab for, og som stiller nye krav til produktet. Der hvor forløbet med Scrum i et solo-projekt ikke har fungeret optimalt har været i forhold til refleksioner. I den forbindelse har det hjulpet mig meget, at jeg har skrevet emner ned til Retrospektive, for i den proces at behandle emnerne en ekstra gang og herefter tage dem op til Retrospektive. Dog har det været svært at anskue tingene på mere end én måde, efter at have arbejdet med dem som både Scrum master og team. Måske Product Owner kunne deltage ved Retrospektive, det kunne give nuancerede refleksioner. Ved XP praktikkerne har det ikke været muligt at lave test først i projektet. Ved udarbejdelsen af filtrering manglede jeg tests for at kunne sikre kodens kvalitet i form af et bedre design og udrydde fejl, mens det var på test serveren. Som helhed vurdere jeg, at Scrum og XP praktikker har hjulpet mig med at kunne levere et produkt af god kvalitet til Product Owner. Det har været utroligt motiverende og givende at have en rigtig kunde i den anden ende med sine krav og ønsker. Efter projektet er afsluttet vil jeg fortsætte samarbejdet med Kalejdoskop for fortsat at optimere deres webshop. Det har været en spændende udfordring at arbejde med en ny teknologi som Magento. Efter projektarbejdet føler jeg mig rustet til også at lave egne moduler til Magento. Udarbejdet af: Ulrik. Side 48 af 53

54 Referencer [1]»Usage Statistics and Market Share of Apache for Websites, June 2015,«1 juni [Online]. Available: [2]»Magento Design guide,«1 juni [Online]. Available: [3]»Atom.io,«1 juni [Online]. Available: [4]»Visual Studio,«1 juni [Online]. Available: [5]»PHPStorm,«1 juni [Online]. Available: [6] sad ,»agile Methods Of Software Development,«ETERNAL SUNSHINE OF THE IS MIND, 3 febuar [Online]. Available: [Senest hentet eller vist den 17 juni 2015]. [7] P. Bell,»Solo-Scrums,«1 juni [Online]. Available: [8]»Extreme Programming For One,«1 juni [Online]. Available: [Senest hentet eller vist den 1 juni 2015]. [9]»Efficient Magento code database (Flat vs EAV). Part 1.,«1 juni [Online]. Available: [10]»About JavaScript - JavaScript MDN,«1 juni [Online]. Available: US/docs/Web/JavaScript/About_JavaScript. [11]»About the Apache HTTP Server Project,«1 juni [Online]. Available: Udarbejdet af: Ulrik. Side 49 af 53

55 [12]»Community & Enterprise ecommerce Solutions,«1 Juni [Online]. Available: [13]»eCommerce Technology & Technical Resources,«1 juni [Online]. Available: [14]»File: SASS_REFERENCE Sass Documentation,«1 juni [Online]. Available: [15]»HTML & CSS - W3C,«1 juni [Online]. Available: [16]»Introduction to Object Oriented Programming Concepts (OOP) and More:,«1 juni [Online]. Available: Concep#OOP. [17]»jQuery,«1 juni [Online]. Available: [18] A. MacGregor,»Magento Fundamentals for Developers PACKT Books:,«1 juni [Online]. Available: [19] R. Bhatia,»Magento MVC Architecture: Rajesh's Tech Blog,«1 juni [Online]. Available: [20]»Magentohotel tech review (magentohotel.dk),«1 juni [Online]. Available: [21]»MySQL 5.6 Reference Manual :: A.1 MySQL 5.6 FAQ: General,«1 juni [Online]. Available: [22]»Patterns in Practice: Cohesion And Coupling,«1 juni [Online]. Available: [23]»PHP: Apache 2.x on Microsoft Windows Manual,«1 juni [Online]. Available: Udarbejdet af: Ulrik. Side 50 af 53

56 [24]»PHP: What is PHP? Manual,«1 juni [Online]. Available: [25]»phpMyAdmin,«1 juni [Online]. Available: [26]»Prototype Overview,«1 juni [Online]. Available: [27]»Understanding Drupal,«1 juni [Online]. Available: [28]»W3C Document Object Model,«1 juni [Online]. Available: [29]»What is LAMP (Linux, Apache, MySQL, PHP)? - Definition from WhatIs.com,«1 juni [Online]. Available: [30]»What is Magento?,«1 juni [Online]. Available: [31]»What is phtml File Extension in Eicra Script,«1 juni [Online]. Available: [32]»Xdebug: Documentation,«1 juni [Online]. Available: [33]»Zend Framework & MVC Introduction - Zend Framework Quick Start,«1 juni [Online]. Available: [34] S. T. Veethil,»Risk Management in Agile,«1 juni [Online]. Available: [35] D. Wax,»Scrum for one,«1 juni [Online]. Available: [36]»Magento 2.0 Update Released: 8 Key Features will Attract You,«1 juni [Online]. Available: Udarbejdet af: Ulrik. Side 51 af 53

57 [37] H. Kniberg, Scrum and XP from the Trenches, InfoQ, [38] C. Larman, APPLYING UML AND PATTERNS, 3 red., Craig Larman: Prentice Hall, 3. udgave, marts [39] I. Sommerville, Systemudviklingsmetode/System development, Software Engeneering, 9. edition, Pearson, [40] M. Cohn, User Stories Applied, For Agile Software Development, Addison-Wesley, Udarbejdet af: Ulrik. Side 52 af 53

58 Bilag 1. Vejledning til medfølgende kilde kode Udarbejdet af: Ulrik. Side 53 af 53

59 Bilag 1: Vejledning til medfølgende kilde kode Medfølgende er filen bilag1-kildekode.zip med kildekode. Medie mappen er undladt på grund af størrelsen. (Opbygningen er som beskrevet i afsnittet Folder struktur på side Fejl! Bogmærke er ikke defineret. i rapporten.) Tema mapperne: Layout filerne er placeret i: Design filerne er placeret i: App/design/frontend/rwd/kalejdoskopRWD Skin/frontend/rwd/kalejdoskopRWD PHP filer: Magento kerne bibliotek: Ændrede Magento kerne biblioteks filer: App/code/core App/code/local Udarbejdet af: Ulrik.