2020-10-07
Att arbeta effektivt inom projekt och sprintar kan ibland vara svårt. Framförallt om ett projektet innehåller olika moment eller jira-tickets som egentligen beror på tidigare moment eller andra jira-tickets, under en och samma sprint.
Det gäller att jobba smart för att förhindra blockers och lösa upp beroenden under sprinten.
Hur jobbar man då egentligen smart för att förhindra blockers och löser upp beroenden?
Det finns så klart en uppsjö olika smarta knep och arbetssätt att ta till sig. Men jag tänkte lyfta fram en grej som hjälpt mig mycket i två projektsprintar under denna höst och det är vikten av att enas om ett dataformat tidigt i sprinten.
Det här är så klart inte applicerbart i alla sprintar eller något som löser upp alla beroenden. Men det är något som många gånger kan tillåta samtidigt arbete mot ett gemensamt sprintmål från flera utvecklare - från olika håll.
Men på vilket sätt hjälper detta en sprint och hur för det med sig effektivare arbete genom att man enas om ett dataformat? Jo... jag tänkte ge två stycken exempel, baserade på de två projektsprintarna jag nämnde tidigare.
De exempel jag tänkte ta upp är bara löst baserade på de uppgifter och mål som de faktiska sprintarna innebar. Jag beskriver bara uppgifterna löst då det är inte uppgifterna i sig som driver poängen.
I första sprinten, som för övrigt varade två veckor, hade jag och en till kollega i uppgift att bland annat (förenklat):
Snabbt märker man ju att den sista punkten har ett beroende på den första punkten, eftersom parsningen av xml-datan till json skulle ske med hjälp av ett npm-paket som servern skulle använda.
För att vi skulle kunna arbeta effektivt spikade vi hur json-datan skulle se ut. I och med detta så kunde vi jobba från två olika håll. En av oss kunde jobba med npm-paketet för att se till att paketet kunde parsa xml-data till det förväntade json-objektet och den andra (jag) jobbade i servern.
Att vi hade bestämt oss för ett dataformat på json-objektet innebar att jag kunde mocka förväntad data tillsvidare och bygga funktionaliteten som behövdes runt det.
Jag kunde skriva enhetstester som gick igenom med mock-data på plats och jag kunde även skriva enhetstester som inte gick igenom förrän då jag kunde byta ut mock-datat. Då gick slutligen alla tester igenom och jag var, i och med testerna, mer trygg med att bytet till riktig data inte drog med sig buggar eller icke-förväntat beteende i servern.
Istället för att vara helt blockad med min ticket kunde jag jag genomföra 90% av ticketen parallellt med arbetet med parsningen, på grund av att vi hade spikat ett gemensamt dataformat.
Andra fördelar: Ytterligare en fördel med att arbeta utifrån samma dataformat från olika håll tidigt i sprinten är att man mer ordentligt testar dataformatet och kan ”känna sig för” på ett bättre sätt. Är dataformatet rimligt? Går det att använda på det sätt vi tänkt oss? Sådana frågor får man snabbare svar på.
I andra sprinten, som också varade i två veckor, hade jag och en till kollega i uppgift att bland annat (förenklat):
Även i det här fallet märker man snabbt att den andra punkten har ett beroende på den första och även här inser man att ett spikat gemensamt dataformat innebär att man kan arbeta mot samma sprintmål från olika håll.
Utifrån dataformatet som REST-endpointen skulle leverera kunde vi arbeta i mot sprintmålet från olika håll parallellt. I mitt fall handlade det om att mocka datat i React frontend:en och rita ut mock-datat med React komponenter.
När endpointen sen var på plats handlade det bara för min del om att byta ut datakällan i en container-komponent i frontend:en från hårdkodad mock-data till att anropa endpointen.
👆 Precis som med allt annat så vill man separera ansvar för React komponenter. Ett vanligt mönster är att man har container-komponenter som ansvarar för att hämta data från datakällor och så har man presentation-komponenter som sköter själva utritningen.
Tanken är då att containern hämtar datan och ger datan som
propstill presentationskomponenten för utritning.
Återigen gjorde det gemensamma dataformatet att jag kunde jobba på en annars blockad ticket till 90% färdig innan de sista 10% gjordes, genom att anropa den faktiska endpointen.
Vad är det jag vill få sagt egentligen? 🤔 Jo... nämligen att man många gånger kan kringgå blockers i projekt/sprintar genom att enas om det dataformat som då och då genomsyrar ett helt projekt eller en hel sprint.
Ett dataformat kan ses som ett kontrakt mellan exempelvis en front- och backend. Att i ett tidigt stadie bestämma hur detta dataformat, eller kontrakt, ska se ut innebär att man kan jobba mer effektivt, hålla antalet blockers nere och mjuka upp beroenden och helt enkelt jobba mer effektivt.