H\u00e4r p\u00e5 Cinnober jobbar vi med en agil utvecklingsmetod som heter Scrum. Agila utvecklingsmetoder har f\u00e5tt en bred spridning i mjukvaruutvecklingsbranschen dom senaste \u00e5ren. Med scrum s\u00e5 delar vi in arbetet i s\u00e5 kallade sprintar som \u00e4r i normala fall \u00e4r 2-5 veckor l\u00e5nga och avslutas med en leverans till kunden i projektet. Arbetet i sprinten delas upp i tickets som inneh\u00e5ller en m\u00e4ngd arbete, detta kan vara vad som helst ifr\u00e5n en bugrapport till nyutveckling av funktionalitet till interna kom-ih\u00e5g-lappar f\u00f6r allt m\u00f6jligt som beh\u00f6vs g\u00f6ras i projektet. Vi anv\u00e4nder ett verktyg som kallas Jira f\u00f6r att hantera detta. I mitt fall p\u00e5 kundprojektet LME Clear sitter det ganska m\u00e5nga testare i London som testar v\u00e5ran senaste leverans och n\u00e4r dom uppt\u00e4ckt en potentiell bug s\u00e5 skriver dom en Jira och skickar till oss. Vi f\u00e5r in denna Jira p\u00e5 en tavla d\u00e4r vi samlar alla Jiror som kommer in fr\u00e5n kund.<\/p>\n
\r\n![\"supJiraBoard\"](\"http:\/\/www.traineebloggen.se\/wp-content\/uploads\/traineebloggen\/2014\/05\/supJiraBoard.png\")
<\/a>\r\n\r\n<\/span><\/code><\/pre>\nProcessen d\u00e4refter \u00e4r att n\u00e5gon p\u00e5 v\u00e5ran sida tar den inkomna Jiran (bugrapporten) och f\u00f6rs\u00f6ker verifiera den. Ibland visar det sig att kunden tror att det \u00e4r en bug n\u00e4r det egentligen inte \u00e4r det eller att deras system inte \u00e4r korrekt installerat. N\u00e4r vi verifierat den som en riktig bug kommer den in p\u00e5 v\u00e5r interna Jira tavla som ser ut ungef\u00e4r s\u00e5 h\u00e4r.<\/p>\n