Programmering i team
Programmering i team
I varje utvecklarteam finns skillnader i kunskapsnivåer, åsikter och personligheter. Kan det ibland vara svårt att acceptera varandras sätt att skriva kod? Finns det en frustration i ert team? I denna blogg går Erik Lenells igenom reflektioner och verktyg att ha med er för att höja kvalitén i ert arbetslag.När teamet inte är överens om beslut eller var fokus bör ligga kan det lätt uppstå en frustration. Ibland är det till och med svårt att acceptera varandras sätt att skriva kod. Hur frustrationen och de konflikter som uppstår hanteras kan ha stor påverkan på hela teamets effektivitet och – kanske än mer viktigt – på arbetslivskvaliteten. Här följer lite reflektioner och verktyg att ha med sig för att höja kvaliteten och teamkänslan i sitt arbetslag.
Diskutera
Samtidigt som det är viktigt att få sitta koncentrerad i sin bubbla är det också viktigt att lära känna sina arbetskamrater genom att diskutera problem och lösningar. I takt med att alla blir införstådda med varandras styrkor, svagheter och sätt att skriva kod utvecklas en förståelse för hur samarbetet ska fungera. Det är en stor fördel för ett team när man är öppen för dialog och söker konstruktiva diskussioner.
Få ert team i rätt riktning
Det kommer finnas tillfällen när man ser att ett beslut kommer ha stor negativ effekt på projektet eller då kodstrukturen börjar bege sig i fel riktning. Till exempel när ett datalager börjar innehålla affärslogik eller när ett ”design pattern” används på fel sätt. Problemet behöver då tas upp innan spagettikoden blir ett oåterkalleligt faktum.
Det kan vara svårt att påpeka fel och brister hos varandra men med genomtänkta argument för de förändringar som behövs blir det lättare att ta en saklig diskussion. Det är också bra att presentera det på ett sätt som ger den andre utrymme att svara. Det kan mycket väl finnas bra motargument.
Att ha Code Reviews/Pull Requests som arbetssätt ger ett enkelt och naturligt sätt att ta upp dessa saker. Om det av någon anledning saknas får man arbeta lite mer på sitt sätt att uttrycka sig. När det är svårt att komma överens är det bra om det finns en uttalad lead developer som kan sätta ner foten.
Med en sådan roll i teamet kan principer utvecklas som håller ihop kodbasen. De gör att den förblir tydlig och enhetlig – det kommer sen ha stor betydelse för förvaltningsbarheten och minskar personberoendet.
Ansvarstagande
De i teamet som tidigt visar ett ansvarstagande för de lite jobbigare problemen kommer både få respekt och bidra enormt till hela teamets välmående och anseende. Det finns också större möjlighet att dra lärdom och känna mer engagemang när man visar framfötterna. Samtidigt är det bra att välja sina tillfällen och inte tävla om prestige. Bäst är att ta ansvar där det känns naturligt eller för de saker som andra i teamet verkar skjuta undan lite.
Tydligt versionshanteringsupplägg
I ett team är det viktigt att det finns ett gemensamt sätt att arbeta med versionshantering. Det uppstår ofta scenarion där viss kod ska produktionssättas längre fram än annan. Ibland vet man inte om allt som jobbas på i dagsläget ska driftsättas samtidigt eller om det ska ut vid olika tillfällen. Då är det viktigt att det finns ett tankesätt kring kodförgreningar som möjliggör många små produktionssättningar. För att få veta mer om vad detta innebär kan man kolla in Github Flow.
Summering
Att jobba med programmering i team medför större komplexitet än att jobba själv. För att hantera komplexiteten behöver vi tänka aktivt på vårt bemötande, hur vi använder våra verktyg och vilka roller vi har i teamet. Till en början känns det mycket lättare att fokusera på sitt och jobba på sitt eget sätt. Tänk på att när projektet växer och får många rörliga delar krävs ett genomtänkt samarbete.
Erik Lenells, Systemutvecklare på Infozone