Flashcards inför Tenta
MVP
MVP, eller Minimum Viable Product, är en metod som används inom agil utveckling för att snabbt skapa och testa en grundläggande version av en produkt eller tjänst. Det är ett sätt att få feedback från användare och kunder tidigt i utvecklingsprocessen och använda detta för att förbättra produkten eller tjänsten. Syftet med MVP är att minimera risken för att skapa en produkt som inte möter kundernas behov eller önskemål. MVP är en iterativ process som fortsätter att utvecklas och utvecklas tills den uppfyller kraven hos kunderna.
XP
(eXtreme Programming) är en metodik för att utveckla mjukvarusystem. Det fokuserar på att leverera fungerande kod så tidigt som möjligt och att använda en iterativ och inkrementell utvecklingsprocess. Det innebär att man börjar med en grundläggande version av programvaran och sedan successivt lägger till nya funktioner och förbättrar befintliga över tid. XP också innebär att man har ett starkt fokus på kommunikation och samarbete mellan utvecklare, och att man använder sig av enkelhet, reflektion och adaptivitet för att hålla projektet på rätt kurs.
XP är en metodik för programvaruutveckling som fokuserar på kontinuerliga och små steg i utvecklingsprocessen, tät kommunikation mellan utvecklare och kund, och enkelhet i koden. Den använder sig av agila principer och syftar till att skapa högkvalitativ mjukvara på ett effektivt sätt genom att involvera kunden i utvecklingsprocessen och genomföra tester tidigt i processen. XP används ofta i projekt med höga krav på flexibilitet och snabba förändringar.
Pair programming
Pair programming är en metod inom XP där två utvecklare arbetar tillsammans vid samma dator för att skapa eller ändra kod. En av utvecklarna, kallad “navigator”, är ansvarig för att tänka ut nästa steg i koden medan den andra, kallad “driver”, skriver koden. De byter sedan roll regelbundet för att få en bredare förståelse för koden och undvika att fastna i en viss tankegång. Pair programming syftar till att öka kvaliteten på koden genom att ha flera par ögon på den, öka kommunikationen mellan utvecklare, och göra det enklare att lära sig nya tekniker och verktyg.
CI/CD
CI/CD står för Continuous Integration / Continuous Deployment. Det är en metodik för utveckling av mjukvarusystem där förändringar i kodbasen automatiskt integreras, byggs och distribueras till produktionsmiljön med hjälp av automatiserade verktyg. Continuous Integration (CI) är processen att automatiskt integrera kodändringar till en gemensam kodbas så ofta som möjligt. Detta gör det möjligt för utvecklare att snabbt identifiera och fixa konflikter i kodbasen. Det är viktigt eftersom det minskar risken för att ändringar ska skapa problem i produktionsmiljön. Continuous Deployment (CD) är processen att automatiskt distribuera förändringar till produktionsmiljön så snart som möjligt efter att de har integrerats och testats. Detta gör det möjligt för verksamheten att snabbt få tillgång till nya funktioner och förbättringar. Tillsammans hjälper CI/CD till att minska riskerna för problem i produktionsmiljön och öka hastigheten på utvecklingen av mjukvarusystem. Det är vanligtvis en del av en större DevOps-strategi som syftar till att öka samarbetet mellan utvecklare och IT-drift teams.
Kodgranskning
Kodgranskning, även känt som code review, är en metod där utvecklare granskar och godkänner kodändringar innan de slås samman med huvudgrenen i ett mjukvaruprojekt. Syftet med kodgranskning är att identifiera och rätta till eventuella fel eller brister i koden så tidigt som möjligt, samt att främja kvalitet, säkerhet och enhetlighet i kodbasen. Kodgranskning kan göras manuellt eller automatiserat, och kan ske både internt i en utvecklingsteam eller mellan olika team. Det kan vara ett viktigt verktyg för att förbättra kodens kvalitet och för att skapa en kultur där medlemmarna hjälper varandra att utvecklas och lära sig.
Sprint reviews
Sprint reviews är tänkt att vara korta och informella möten där projektmedlemmarna kan diskutera och samarbeta för att säkerställa att projektet rör sig i rätt riktning och att det levererade arbetet möter kraven och förväntningarna. Det ger också teamet möjlighet att snabbt anpassa sig till förändringar och förbättra projektets processer. Det är viktigt att notera att sprint review är en regelbunden del av agil projektutveckling och att det är avgörande för att säkerställa att projektet förblir på rätt väg och att det levererar värde till kunden. Det är också viktigt att intressenterna är involverade i sprint review för att säkerställa att det levererade arbetet möter deras krav och förväntningar.
Sprint retrospective
Sprint retrospective är en viktig del av agil produktutveckling där projektmedlemmarna regelbundet träffas för att diskutera vad som fungerade bra och vad som kan förbättras under den aktuella sprinten. Syftet med retrospective är att identifiera och förbättra projektets processer och arbetsmetoder för att säkerställa att projektet fortsätter att leverera värde till kunden. Projektmedlemmarna börjar med att reflektera över vad som hände under sprinten, identifierar orsakerna till problem och utmaningar som uppstod och diskuterar och föreslår lösningar för att förbättra projektets processer och arbetsmetoder. Teamet väljer och åtar sig åtgärder för att genomföra de föreslagna lösningarna. Sprint retrospectives är tänkta att vara korta och informella möten där projektmedlemmarna kan öppet diskutera och samarbeta för att förbättra projektets processer och arbetsmetoder. Det ger också teamet möjlighet att snabbt anpassa sig till förändringar och förbättra projektets prestanda. Genom att regelbundet genomföra sprint retrospectives så kan teamet ta reda på vad som fungerar och vad som inte gör det, samt identifiera och åtgärda eventuella problem och utmaningar i ett tidigt skede, vilket ökar chansen att projektet levererar värde till kunden och når sina mål.
Estimering
Estimering inom agil projektutveckling syftar till att få en uppskattning av den tid och kostnad som krävs för att genomföra en viss uppgift eller ett projekt. Det används för att planera och hålla koll på projektets framsteg och budget. I agila metoder används ofta en enkel och flexibel metod för estimering, såsom “story points” eller “sprint points”. Dessa är ett abstrakt mätetal för svårighetsgraden av en uppgift, som kan jämföras med andra uppgifter för att få en uppskattning av den totala tiden och kostnaden för projektet. Detta gör det möjligt för teamet att anpassa sig till förändringar och ändringar i krav under projektets gång, utan att behöva göra om alla estimeringar från grunden.
Man kan estimera på flera olika sätt, man kan till exempel estimera inom poäng, storlek eller tid (timmar).
Genom att dela upp projekt i mindre delar så kan man göra projektet lättare. Genom att dela upp de i mindre moment så underlättar man för sig själv.
Genom att jämföra med tidigare erfarenheter, fråga en expert eller att beräkna en uppgift genom en matematisk modell kan man få en bättre estimation.
Att tänka på vid estimering: Ha en mall, det blir en bra grund att utgå ifrån. Komplexiteten påverkar säkerheten hos ett estimat, alltså om det är ett väldigt komplext projekt så kommer estimatet bli allt svårare. Kundens utbildningsnivå påverkar, om en kund är okunnig inom ett ämne kommer de ta längre tid då man måste visa och förklara hur de ska använda produkten.
DEEP
Detailed approach - Man gör en tidsplanering, man ser alltså vad som ligger nära i tiden och man ser vad som bör göras närmast i tiden gentemot vad som kan prokastineras.
Estimate - Estimationer kring arbetet. Här kan man använda sig av story points.
Emergent - Hur brådskande det är /vad som ska göras/lanseras först från backloggen.
Prioritized - Vad som ska prioriteras och hur de ska prioriteras i ett projekt.
User story
En “User Story” är en metod för att beskriva och organisera krav och funktioner i ett projekt. Det är ett kort och informellt beskrivande av en funktion eller en förbättring som ska göras för att möta behoven hos en användare eller kund. Det är vanligtvis skrivet i första person och beskriver vad en användare vill göra och varför. User stories används ofta i agila projektmetoder för att hjälpa utvecklar teamet att förstå och prioritera kraven på ett projekt.
Acceptanskriterier
Acceptanskriterier är de kriterier som används för att avgöra om en User Story är färdigt implementerad och kan accepteras av användare eller kunder. De definierar precis vad som krävs för att en User Story ska anses vara komplett och möta de specifika kraven. Acceptanskriterier kan vara både funktionsrelaterade och kvalitetsrelaterade. Exempel på funktionsrelaterade acceptanskriterier kan vara “systemet ska kunna söka efter produkter” eller “användaren ska kunna lägga till en produkt i sin varukorg”. Exempel på kvalitetsrelaterade acceptanskriterier kan vara “systemet ska vara snabbt” eller “användargränssnittet ska vara enkelt att använda”. Acceptanskriterierna ska vara mätbara, detta för att det ska vara möjligt att verifiera om de uppfylls eller inte.
Epic Story
“Epic Stories” är en större typ av User Story som beskriver en mer omfattande funktion eller ett mål för ett projekt. De är vanligtvis mer abstrakta och kan innehålla flera mindre User Stories. Epic Stories är ofta använda i agila projektmetoder för att organisera och prioritera kraven på ett projekt. De hjälper utvecklarteamet att se helheten i projektet och förstå hur de mindre User Stories som utgör den Episka berättelsen hänger ihop. Ett exempel på en Epic Story kan vara “Implementera en e-handelssida” som kan innehålla User Stories som “Implementera en produkt-sökfunktion”, “Implementera en varukorg funktion” eller “Implementera en betalfunktion”.
Invest
Independent - Negotiable - Valuable - Estimable - Small - Testable
Ett user story bör vara oberoende från andra user stories, förhandlingsbart vad gäller detaljer, värdefullt för användaren, uppskattningsbara vad gäller tid och kostnad, litet och testbart. Detta hjälper till att säkerställa att user storyn är enkel att förstå och genomföra.
Definition of done
“Definition of Done” (DoD) är en term som används inom agila utvecklingsmetoder för att beskriva vilka kriterier som måste uppfyllas för att en uppgift ska anses vara färdig. DoD är en del av en övergripande planering och är viktig för att säkerställa att alla teammedlemmar är på samma sida om vad som förväntas av en uppgift.
DoD innebär att alla krav som satt för en uppgift är implementerade, testade och godkända. Det kan innefatta kvalitetskontroll, kodgranskning, enhetstester, integrationstester, dokumentation och annat som är relevant för projektet.
En viktigt aspekt av DoD är att det är ett levande dokument, som kan ändras över tid, beroende på projektets utveckling och förändringar i kraven.
DoD är viktigt eftersom det hjälper till att säkerställa att alla teammedlemmar har en gemensam förståelse för vad som krävs för att en uppgift ska betraktas som färdig, samt hjälper till att minimera risken för missförstånd och förseningar i projektet.
SWOT-analys
En SWOT-analys är en strategisk analysmetod som används för att identifiera en organisation eller en projekts styrkor, svagheter, möjligheter och hot.
Styrkor och svagheter är interna faktorer som har en inverkan på organisationens prestanda. Möjligheter och hot är externa faktorer som påverkar organisationen.
Syftet med en SWOT-analys är att hjälpa beslutsfattare att förstå företagets situation och identifiera strategier för att uppnå sina mål.
