Når kommunikasjon mellom frontend og backend fungerer sånn passe…
Det finnes mange memes og humoristiske skråblikk på forskjellen mellom frontend og backend, og med god grunn! Jeg tror ikke jeg er alene om å ha opplevd at samarbeid mellom front- og backendutviklere til tider kan skrangle i skjøtene, og jeg er nok heller ikke alene om å være post-prosjekt-etterpåklok av typen “hvis jeg bare hadde gjort X eller teamet hadde etablert verktøy Y…”
I min egen jobb som utvikler ser jeg tre viktige elementer som påvirker samarbeidet mellom frontend og backend:
- Teknologi og konvensjoner
- Retorikk, roller og teamkultur
- Metodikk
Teknologi og konvensjoner
Plattformer og teknologi følger ofte sine særegne konvensjoner og beste praksis. Utviklere som jobber med teknologien blir naturlig påvirket av disse når vi selv skal ta valg rundt f.eks. navngivning, strukturering, arkitektur eller modellering.
I et nyutviklingsprosjekt hvor vi rullet ut nye leveranser etter hver sprint, opplevde vi at det stadig var små avvik i forventninger til payload mellom frontend og backend. Til slutt måtte vi gjennomføre det som nesten ble en ukentlig “due diligence” for å sjekke avstanden mellom frontend og backend i forventning til schema. Dette var altså før vi fikk integrasjonstester og schema-validering på plass.
Koden i frontend sluttet å fungere da payload gikk fra å utelate “owner” til å levere objektet med null-verdi. Du kan lese mer om object destruction med default verdi her.
Hvis du som leser dette tenker at eksempelet ovenfor i bunn og grunn handler om dårlig kommunikasjon eller kanskje svak typesjekking, så har du selvsagt helt rett. Jeg kommer til det punktet! Poenget mitt her er å demonstrere hvordan utviklere tar kodevalg som isolert sett gir mening ut fra egen teknologi og konvensjon, men som skaper gnisninger når løsninger man lager skal fungere sammen.
Retorikk, roller og teamkultur
Selv om mange utviklere har en fullstack-kompetanse, skilles det relativt tydelig mellom frontend- og backendroller. Skillet er i mange tilfeller både naturlig og kanskje også nødvendig. Men det kan være en fordel for teamet å være bevisst på konsekvensene hvis skillet og avstanden blir for stor. Med avstand tenker jeg ikke bare på fysisk plassering i et post-corona kontorlandskap, men også avstand i møtepunkter, opplevd eierskap eller noe så enkelt som retorikk og ordbruk innad i teamet.
“…aner ikke, det må du ta med backend.”
“…dataene i payload er riktige, så sjekk hva frontend gjør med de!”
Kommentarene ovenfor er jo ikke vondt ment, men de skaper like fullt en retorisk avstand mellom fagene. Selv har jeg også vært ubetenksom i denne måten å snakke på.
Varierende former for avstand mellom roller, enten de er fysisk eller opplevd, gjør også at dørstokkmilen kan føles høy for å stille spørsmål, stikke frem hodet eller invitere til en kjapp diskusjon. Det samme gjelder ofte dersom teamet ikke kjenner hverandre spesielt godt. Dermed er det fort gjort å bli sittende og jobbe med ryggen mot hverandre, spesielt dersom det ikke er etablert en god teamkultur. Og det er slik man ender opp med dårlig kommunikasjon, hvor frontend forventer undefined, mens backend bare tillater null.
I en travel sprint med mange leveranser fikk jeg et litt ukurant utformet schema i en payload. Det var ikke noe galt med schemaet i seg selv, men måten jeg hadde bygget opp frontend gjorde at jeg måtte skrive noen ekstra linjer for å “tygge om” dataene jeg fikk fra backend før de kunne presenteres i UI. En liten justering i payload hadde egentlig løst problemet.
…i ettertid ser jeg at dette var et symptom på min manglende trygghet og kjennskap i teamet.
Det var allerede litt dårlig stemning i teamet, så jeg droppet rett og slett å ta “enda en diskusjon om payloaden”. Istedet bestemte jeg meg for å bruke de dataene jeg fikk. Isolert sett var dette en fille-sak, men i ettertid ser jeg at dette var et symptom på min manglende trygghet og kjennskap i teamet.
Dette går selvsagt begge veier. Jeg er sikker på at backendutviklere som jeg har jobbet med har tenkt at “jeg får det jeg får fra frontend, og så vasker og normaliserer jeg heller dataene selv. Dette påvirker følelsen i teamet, i tillegg til reell fremdrift. Vi diskuterer teknologi til fanden tar oss, men så gjør vi allikevel all formatering av data dobbelt opp.
Derfor er kultur og åpenhet i et team så viktig — det er grunnlaget for at man skal “orke” å gå den ekstra runden med kollegaer, selv om alle har mye å gjøre og presset for å levere er høyt.
Metodikk
Innenfor hver sprint har teamet blitt enige om å levere et visst sett med funksjonalitet, ihvertfall dersom de jobber Scrum. Ufordringen ligger i at vi ikke alltid har et godt rammeverk til å håndtere avhengigheter mellom oppgavene som skal gjøres.
Teamet skulle lage et reservasjonsskjema. Etter at behovene er beskrevet, skal UX og arkitekt løse brukerreisen og hva slags data som skjemaet skal hente inn ut ifra et domene- og forretningsperspektiv. Deretter satte backendutvikler opp nødvendige tjenester og API-endepunkter slik at frontendutvikleren hadde noe å gjøre kall mot.
Her hadde teamet, til tross for scrum-metodikken, en form for vannfall i sprinten hvor hvert teammedlem venter på at det forrige leddet skal levere nok arbeid til at den neste kunne begynne. Dersom det oppstod misforståelser et stykke ut i sprinten måtte kanskje forrige ledd gjøre endringer før neste teammedlem kunne fortsette jobben sin.
Konsekvensen av dette ble at teamet enten måtte ta andre planlagte oppgaver ut av sprinten fordi tiden ble for knapp, eller leverte kode som var “god nok i denne omgang”. Det siste er som kjent roten til kodegjeld på lengre sikt.
Hvilke grep kan vi ta?
Såkalte “soft skills”, blant annet respekt for hverandre og evnen til å lytte kan virke som forslitte selvfølgeligheter, men de er viktige hjørnesteiner i et teamsamarbeid. I noen team er dessverre disse hjørnesteinene mangelvare! Når det er sagt, så er verktøy og metodikk innen teambygging et helt eget fag som andre kan bedre enn meg, og det blir et for stort tema i denne artikkelen.
Et verktøy som jeg derimot vil nevne mer konkret og som kan motvirke vannfallsproblematikken som jeg nevnte tidligere er scrum swarming.
Kort oppsummert handler dette om at teamet samler seg om et konkret problem eller en funksjon som de har identifisert som teknisk krevende. Teamet diskuterer, skisser og modellerer enten på ark eller whiteboard (eller for tiden digitalt).
Når vi har blitt enige om hvordan problemet kan angripes og løses, er teorien at vi skal kunne arbeide litt mer mer parallelt iløpet av sprinten enn vi kanskje ellers ville ha gjort. Jeg bruker ordet “teorien” fordi det er alltid er forskjell mellom metodikk på papiret og hva som er praktisk gjennomførbart ute i felten. Men intensjonen og konseptet rundt scrum swarming synes jeg allikevel står seg bra!
Ved å også bruke scrum swarming som fast verktøy ved sprintstart for funksjoner som er litt ekstra krevende oppnår teamet et kinderegg av fordeler:
- Vi får en bedre forståelse av hva som skal til for å løse funksjonen, hvor kompleksiteten ligger, i tillegg til at vi plukker vekk forskjeller i oppgaveforståelsen allerede fra start.
- Enkle wireframes og en mockup-json av nødvendige payloads er eksempler på verktøy som gir en god felles “blueprint” som gjør at vi kan jobbe mer parallelt og likevel oppleve at puslespillbitene passer sammen når tiden nærmer seg sprintdemo.
- Vi blir bedre kjent med hverandre og får en bedre grobunn for samarbeid når vi bevisst setter av tid til å diskutere en konkret problemstilling. Vi ser oppgaven fra forskjellige vinkler og skaper oss et omriss av hva vi skal lage denne sprinten i stedet for å kun sende dokumentasjon tekstlig via Slack og Confluence.
Jeg tror i grunnen alle mennesker i et team ønsker seg et godt samarbeid — ikke minst frontend- og backendutviklerne! I alle tilfellene hvor jeg har opplevd at teamet eller prosesser ikke har fungert så godt har det sjelden handlet om enkeltmennesket, men snarere om hvilke verktøy eller metodikk som teamet har brukt, hvor godt vi har kjent hverandre og hvor åpen kulturen har vært.
Litt mer bevissthet rundt kommunikasjon og retorikk, samt noen grunnleggende prinsipper og verktøy, kan være det som skal til for at frontend- og backendutviklerne har både overskudd og lyst til å gå den ekstra runden sammen slik at vi leverer et enda bedre produkt.
