Optimering af agile arbejdsgange: Bedste praksis, samarbejde og etiske standarder hos Tikweb

I denne artikel tager vi dig med bag kulisserne i vores Agile- og Scrum-workflow og viser, hvordan vi udnytter disse metoder til at strømline driften, fremme samarbejdet og levere enestående resultater.

Agilt fundament:

Vi har taget de agile principper til os som hjørnestenen i vores projektledelsesfilosofi. Agile giver os mulighed for at tilpasse os hurtigt til skiftende krav, prioritere kundetilfredshed og fremme løbende forbedringer. Ved at omfavne agile værdier som fleksibilitet, samarbejde og kundecentrering lægger vi grunden til succes i alle de projekter, vi påtager os.

Forståelse af Scrum:

Inden for vores agile ramme er Scrum vores foretrukne metode til at organisere og udføre projekter. Scrum giver en struktureret ramme for iterativ udvikling, der gør det muligt for tværfunktionelle teams at samarbejde effektivt og levere værdi trinvist.

Scrum-roller:

Produktejer:

Product Owner er ansvarlig for at repræsentere interessenternes interesser og sikre, at Scrum-teamet leverer maksimal værdi. De prioriterer backloggen, definerer brugerhistorier og giver vejledning om produktets vision og retning.

Scrum Master:

Scrum Master fungerer som en tjenende leder for Scrum-teamet, der faciliterer møder, fjerner forhindringer og fremmer en kultur med løbende forbedringer. De sikrer, at Scrum-principperne overholdes, og hjælper teamet med at maksimere dets produktivitet og effektivitet.

Softwareudviklingsteam:

Softwareudviklingsteamet består af tværfunktionelle medlemmer og er ansvarlig for at levere produktforøgelsen. De arbejder tæt sammen og udnytter deres forskellige færdigheder og ekspertise til at nå sprintmålene og levere løsninger af høj kvalitet.

Komponenter i Scrum-arbejdsgangen:

Udvikling af backlog:

Produktejeren samarbejder med interessenter om at udvikle og prioritere produktbackloggen og sikrer, at den afspejler projektets skiftende behov og prioriteter.

Frigivelse af backloggen:

Når backloggen er forfinet og prioriteret, frigiver produktejeren den til sprintplanlægning, hvilket giver Scrum-teamet en klar køreplan for opgaver og mål for det kommende sprint.

Sprint-arbejde:

Vi arbejder i sprint. Hvert sprint varer typisk 1-4 uger, og den mest almindelige længde er 2 uger. Vores tilgang til sprintlængder er adaptiv; vi starter ofte med kortere sprints for nye projekter og justerer, efterhånden som vores kunder kommer med.

Scrum- eller sprintmøde:

I begyndelsen af hvert sprint mødes Scrum-teamet til sprintplanlægning, hvor de definerer sprintmålet og udvælger de punkter på backloggen, der skal færdiggøres. Derudover holder de Sprint Review- og Sprint Retrospective-møder i slutningen af hvert sprint for at indsamle feedback og reflektere over deres proces.

Daglige stand-ups og teamsamarbejde

Vores daglige rutine starter med stand-up-møder om morgenen, hvor teamledere og udviklere mødes for at diskutere igangværende problemer og planlægge den kommende dag. Disse møder er et vigtigt kontaktpunkt for at afstemme teamets indsats og håndtere eventuelle forhindringer i realtid. Derudover gennemgår teamledere fremskridt med interessenter eller CTO på ugentlig basis for at sikre løbende feedback og tilpasning til projektets mål.

Problemets livscyklus og sporing af fremskridt

Når en udvikler begynder at arbejde på et problem, flytter de dets status til “I gang”. Når det er færdigt, overgår det til “Test”, hvor interessenter eller teamledere gennemgår det. I vores iterative proces er der hyppige feedbacksløjfer; hver morgen efter stand-up-møder vurderer interessenter eller teamledere problemer i “Test”-status og godkender dem enten eller flytter dem tilbage til “I gang”, hvis der er behov for yderligere arbejde.

Sprintafslutning og rapportering

Ved afslutningen af hvert sprint udarbejder teamet en sprintrapport og deler den i vores virksomheds Slack #tech-team-kanal. Denne rapport opsummerer det arbejde, der er udført i løbet af sprinten, og fremhæver godkendte ændringer, der er klar til produktion. Projektmedarbejderne bruger derefter disse oplysninger til at informere kunder/partnere og integrere færdige funktioner i markedsførings- og salgsmateriale, f.eks. nyhedsbreve og hjemmesideopdateringer.

Oprettelse og håndtering af problemer

Processen med at oprette og administrere problemer er strømlinet for at sikre effektivitet og klarhed:

• Vi bruger Jira til problemsporing og vedligeholder en række forskellige problemtyper, herunder bugs, ideer, historier, opgaver og epics.

• Til fejlrapporter eller problemer, der kræver skærmbilleder, bruger vi Marker.

• Vores issue-skabeloner i Jira guider oprettelsesprocessen og sikrer konsistens og fuldstændighed i issue-beskrivelserne.

• Hastende problemer håndteres gennem en defineret procedure, der involverer dialog mellem nøgleinteressenter og omhyggelig overvejelse af sprintkapaciteten.

Retrospektiv planlægning af sprint og opfølgning:

Ved afslutningen af hvert sprint gennemfører Scrum-teamet et retrospektiv for at reflektere over deres proces, fejre succeser og identificere områder, der kan forbedres. De bruger derefter disse indsigter til at informere deres planlægning for det næste sprint, hvor de løbende forfiner og optimerer deres arbejdsgang.

Testing

Test spiller en central rolle i vores udviklingsproces hos Tikweb og sikrer, at vores løsninger lever op til de højeste standarder for kvalitet og pålidelighed. Gennem hele sprinten gennemfører softwareudviklingsteamet grundige tests for at sikre kvaliteten og funktionaliteten af produktforøgelsen og identificerer og løser eventuelle fejl eller problemer, når de opstår. Her er en oversigt over vores testpraksis og arbejdsgange:

1. Test af teknisk team:

Test af udviklere: Udviklere udfører manuel testning i lokale miljøer eller på vores udviklingsserver (DEV) for at validere deres arbejde og fange eventuelle umiddelbare problemer.

Automatiseret enhedstestning: Vi udnytter Laravel Dusk og Percy til automatiseret enhedstestning i vores testmiljø (TEST). Det giver os mulighed for effektivt at køre regressionstests og sikre stabiliteten i vores kodebase.

2. Gennemgang af interessenter og teamledere:

Projektmedarbejdernes interessenter er involveret i at teste problemer og give feedback. Godkendte problemer flyttes derefter videre i workflowet.

Derudover udfører teamledere manuelle tests i vores kvalitetssikringsmiljø (QA) for at sikre, at problemerne opfylder de nødvendige standarder, før de godkendes til produktion.

3. Håndtering af større problemer:

I tilfælde, hvor problemer anses for at være store eller have vidtrækkende konsekvenser, opretter udviklere eller teamledere testproblemer med specifikke instruktioner til medarbejdernes testning. Disse testproblemer er knyttet til det oprindelige problem, hvilket sikrer omfattende testdækning.

4. Sprintafslutning og gennemgang:

Hver anden mandag morgen flyttes uløste problemer til næste sprint, mens godkendte problemer opdateres i vores produktionsmiljø (PROD) og markeres som “færdige”.

I slutningen af hvert sprint gennemgår medarbejderne de færdige problemer på PROD for at sikre, at de lever op til forventningerne. Denne gennemgang finder typisk sted mellem onsdag og søndag, hvilket giver rigelig tid til grundig evaluering.

5. Test og evaluering af partnere:

Nogle problemer kan kræve test fra eksterne partnere, især for nye funktioner eller integrationer. Partnere, der har anmodet om funktionen, inviteres til at teste og evaluere funktionaliteten, enten under sprinten i vores testmiljø eller efter sprintens afslutning i PROD. Denne fleksibilitet giver mulighed for fælles feedback og iterative forbedringer.

6. Endelig kvalitetssikring og udrulning:

Når en Jira-version er færdig, skubbes ændringerne til vores kvalitetssikringsmiljø (QA) (qa.xxx.xx) til endelig test. Dette miljø kører på en kopi af vores PROD-sites rigtige data, hvilket giver et realistisk testmiljø.

Når ændringerne har bestået den endelige QA, implementeres de i vores produktionsmiljø (PROD), hvilket sikrer, at vores kunder modtager stabile og pålidelige opdateringer.

Kort sagt sikrer vores strenge testpraksis og samarbejdsorienterede tilgang til kvalitetssikring, at vi leverer løsninger, der opfylder vores kunders og interessenters behov og forventninger. Ved at prioritere grundig testning i alle faser af udviklingens livscyklus opretholder vi vores forpligtelse til ekspertise og kundetilfredshed.

Omgivelser

Vi bruger op til 5 forskellige miljøer. Hvor mange vi bruger, afhænger generelt af, hvor i projektkøreplanen vi befinder os. I begyndelsen er der måske kun et lokalt miljø. Senere i projektet bør alle 5 miljøer køre og bruges.

Direkte serverlogins på PROD-sites bruger gule prompter og markeringer.

De 5 miljøer (lokalt, DEV, TEST, QA, PROD)

PROD = Produktion = App

Direkte serverlogins på PROD-sites bruger gule prompter og markeringer.

QA = Kvalitetssikring

Direkte serverlogin på QA-sider, bruger lilla prompter og markeringer.

QA er vores staging-miljø, navngivet QA for at gøre det lettere for kunderne at forstå, da QA er en forkortelse for Quality Assurance.

TEST = Testning

Direkte serverlogin på TEST-sider, bruger grønne beskeder og markeringer.

DEV = Udvikler

Lokal = Det lokale miljø på udviklerens egen lokale maskine

WWW = Markedsføringssite

DEMO = Demonstration

Eksterne miljøer for PROD og TEST

Håndtering af presserende produktionsproblemer

Når man støder på fejl 500 eller andre kritiske problemer, er det vigtigt at handle hurtigt for at opretholde systemets stabilitet og kundernes tilfredshed. Enhver fejl 500 i Slack prod-error-kanalen skal rettes og sendes til PROD så hurtigt som muligt.

Protokol for øjeblikkelig reaktion:

Når udviklerne opdager en fejl 500 eller et andet kritisk problem, tager de straks fat på problemet og sender de nødvendige rettelser til vores produktionsmiljø (PROD) uden forsinkelse.

For at fremskynde løsningsprocessen tilføjer udviklerne Chief Technical Officer (CTO), Team Manager og Product Owner som watchers på det tilsvarende Jira-problem. Det sikrer, at de vigtigste interessenter får besked om problemet og dets fremskridt.

Udvikleren fortsætter derefter med at skubbe rettelsen til både test- (TEST) og produktionsmiljøerne (PROD) og markerer problemet som “Done” i Jira. Dette udløser automatiske notifikationer til overvågerne og holder alle informeret om problemets løsningsstatus.

Kommunikation og gennemsigtighed:

I tilfælde, hvor det er nødvendigt med et øjeblikkeligt push til PROD, men det ikke er blevet diskuteret med teamet, giver udviklerne en kort forklaring i Jira-problemet. Det sikrer gennemsigtighed og klarhed om, hvor meget det haster med rettelsen.

Derudover kommunikerer udviklerne løsningen på problemet i Slack-kanalerne #prod-error og #tikweb-prod-error. De bekræfter, at fejlen er blevet rettet i både TEST- og PROD-miljøer, ledsaget af et link til det tilsvarende Jira-problem til reference.

Forbedret samarbejde med integrationer

En af disse integrationer er Slack, som fungerer som vores centrale knudepunkt for kommunikation og koordinering i hele virksomheden.

Kanalen #tech-team:

Kanalen #tech-team i vores Slack-arbejdsområde letter den direkte kommunikation mellem CEO, CTO og Tech Team Manager. Mens den daglige drift typisk involverer kommunikation, der går fra CEO til CTO og derefter til Tech Team Manager, giver denne kanal en direkte kommunikationslinje til strategiske diskussioner og beslutningstagning.

I de indledende faser af app-udviklingen, især indtil version 1.0 er opnået, kan #tech-team-kanalen bruges til at diskutere komplekse spørgsmål, der kræver input fra både tekniske og forretningsmæssige perspektiver. Men når appen er lanceret, skal den kun bruges til hastesager, f.eks. kritiske produktionsfejl, der kræver øjeblikkelig opmærksomhed, når CTO’en ikke er til stede.

Det er vigtigt at være forsigtig, når man bruger #tech-team-kanalen, da den kan forstyrre den daglige arbejdsgang for Tech Team Manager og udviklere, der er involveret i igangværende sprints og problemløsning.

Fremme af effektiv arbejdsetik

Vi følger et sæt vejledende principper, der beskriver, hvordan vores forretnings- og tekniske afdelinger samarbejder for at sikre effektiv udvikling og overholdelse af deadlines. Denne etik er afgørende for at opretholde produktiviteten, fremme et positivt arbejdsmiljø og levere løsninger af høj kvalitet til vores kunder.

Respekt for udviklernes fokus:

Vi forstår, hvor vigtigt det er, at udviklere kan fokusere uafbrudt på komplekse kodningsopgaver. Afbrydelser kan forstyrre deres flow og mentale klarhed og potentielt sætte dem tilbage med op til 30 minutter, mens de rekalibrerer og refokuserer.

For at mindske denne risiko prioriterer vi at minimere unødvendige afbrydelser og give udviklerne det rum og den tid, de har brug for til at fordybe sig i deres arbejde. Det øger ikke kun produktiviteten, men beskytter også mod at bringe sprint-tidslinjerne i fare.

Fremadrettet planlægning:

Ved starten af hvert sprint lægger vi vægt på omhyggelig planlægning og afstemning mellem udviklere, teamledere og CTO. Sammen vurderer og prioriterer vi omhyggeligt de problemer, der er planlagt til sprinten, og sikrer, at de udgør en håndterbar arbejdsbyrde inden for den angivne tidsramme.

Når et sprint er indledt, fastholder vi en lukket tilgang, hvilket betyder, at der ikke tilføjes nye problemer midt i sprinten. Denne forpligtelse til forudgående planlægning og aftalte opgaver minimerer risikoen for at afspore sprint-tidslinjen og hjælper med at forhindre, at der opstår uforudsete fejl eller komplikationer.

Ved at opretholde denne arbejdsetik dyrker vi en kultur med respekt, samarbejde og ansvarlighed i vores teams. Det gør os i stand til konsekvent at leve op til vores forpligtelser, overholde projektdeadlines og overgå kundernes forventninger.