Ørjan Markhus Lillevik og Kari Røssland Steria AS

Presentasjon om: "Ørjan Markhus Lillevik og Kari Røssland Steria AS"— Utskrift av presentasjonen:

1 Ørjan Markhus Lillevik og Kari Røssland Steria AS
Parprogrammering kan raskt gi en driv i teamet ditt som du ellers bare kan drømme om Ørjan Markhus Lillevik og Kari Røssland Steria AS

2 Ørjan: Vi jobber i et stort smidig prosjekt med flere utviklingsteam i det som kanskje er norges største smidige offentlige prosjekt. For ett år siden startet et team som tok parprogrammeringen sin veldig på alvor. Du var jo en del av dette teamet Kari. Husker en samtale ganske kort tid etter at dere hadde startet hvor du virket litt frustrert over denne måten å jobbe på. Hva forårsaket dette?

3 ”Parprogrammering var intenst og slitsomt i starten…”
Vi parprogrammerte og roterte partner og oppgave hver eneste dag. Vanskelig å gi fra seg uferdig oppgave Vanskelig å finne sin rolle i de ulike parene Kari: I februkar i år blei eg med i eit nyoppstarta team i prosjektet som bestod av både kjente og heilt ukjente folk. Eg trur vi blei utsatt for eit slags ufrivillig sosialt eksperiment –… då vi blei ”tvunget” til å parprogrammere kvar einaste dag, heile dagen fra dag 1. Vi hadde i tillegg ein regel som gjekk ut på at me skulle rotera partner og oppgave som me jobba på kvar morgon. Dette var veldig intenst og slitsomt. Det var noko nytt kvar einaste dag – ny partner og ny oppgave. Denne regelen for rotering av partner og oppgave føltes veldig påtvunget – og det var vanskelig å forstå poenget med kvifor me måtte gjera det. Det var vanskelig å gi frå seg ei oppgave som du så vidt hadde fått jobba litt med dagen før – ”den var jo ikkje ferdig!”, ”me hadde jo tenkt ut den bra løysinga, men kva var poenget med det – siden vi ikkje får fullført?!”, ”Så pinlig! – no kommer nokre andre til å sjå kor dårlige me er til å programmere – for me rakk ikkje å refaktorere den 100 linjer lange metoden i går.” Det var vanskelig å finne sin rolle i dei ulike para. Nokre gonger blei eg utålmodig fordi det gjekk for sakte. Andre gonger blei eg usikker fordi den andre var flinkare enn meg og eg klarte ikkje lenger å henga med på det som foregjekk på skjermen. Naturlig nok – sidan me var eit nytt team så kjente me ikkje kvarandre, og me visste for lite om kvarandre til å kunne jobba saman på ein effektiv måte. Eg var og bekymra for effektiviteten – ting fungerte ikkje… På slutten av dagen var eg heilt utkjørt…

4 Ørjan: Ser at dere fortsatt jobber i par og at dere har fortsatt å rotere. Det  må vel bety at dere har funnet noe som fungerer for dere. Kva er det som har hendt?

5 ”…,men det gikk bedre etter hvert.”
tilpassa regel for rotering av partner og oppgave unntak fra regelen er lov lærte hvilke roller vi bør spille i de ulike parsammensetningene Kari: Vi har tilpassa regelen for rotering av parther og oppgave – vi roterer fremdeles partner hver dag, men en uvikler bytter oppgave kun annenhver dag – kommer tilbake til dette. Unntak frå regelen er lov – har eg ein dårlig dag er det heilt greit å sitte aleina den dagen. For eksempel. Vi kjenner kvarandre godt no – og har lært kva rolle vi måtta ta i dei ulike parsammensetningene for at vi skulle utnytte kvarandres sterke sider på ein best mulig måte – og lære kvarandre det vi ikkje kan så godt. Vi er effektive – og vi ser fordelene med parprogrammering og ikkje minst dei ekstra fordelene vi vinner ved å rotere partner og oppgaver.

6 Ørjan: Du snakker om tilpassning av rotering av partner og oppgave som et suksesskriterium for dere. Tror det kan være interessant om vi går litt mer i dybden. Hvordan roterer dere?

7 Som hovedregel roterer vi partner hver dag og oppgaver minst annenhver dag.
Oppgave X Oppgave Y Cato Robert Kari Erlend Ivar Andreas Kari: Som hovedregel roterer vi partner kvar dag og oppgaver annekvar dag. Eg blir sittande to dager med samme oppgave. 1. dagen 2. dagen 3. dagen

8 Fordeler med rotasjon av partner og oppgaver når man parprogrammerer
Lærer av hverandre Ensartet kodebase Alle har oversikt God kodekvalitet Rask integrering av nye team-medlemmer Reduserer trikkefaktor-problemet Eg lærer forskjellige ting fra ulike partnere, i tillegg lærer eg bort det eg kan. Alle har sine områder som vi er gode på – så når vi deler kunnskap blir vi mykje betre utviklarar. Me forhandler løysingsmuligheter og løysingsmetodar i dei ulike para. Og sidan parene roterer har me på denne måten har me utvikla ein felles måte å løyse standard problemstillingar på for heile teamet. Dette gir oss ein einsarta kodebase. Uansett kva kode eg ser på, kjenner eg meg igjen – og det er enkelt å forstå koden. Siden alle utviklarane på teamet er innom dei fleste oppgavene som blir løyst – har vi alle ei oversikt over heilheten i det teamet produserer. Kodekvaliteten blir god, siden fleire par er innom samme oppgava og løysinga blir vurdert og revurdert fleire gonger. Når man eg og partneren min veit at andre skal sjå på koden allerede neste dag tvinges vi til å gjera ting heilt ferdig og klar til overlevering, blir på en måte som en liten leveranse annenhver dag. Erlend på teamet mitt seier at han aldri har jobba på en kodebase med så få "TODO"er som du gjerne bruker som ei huskelista for deg sjølv når ein jobber på samme kode aleine over lengre tid. Ivar var ny på teamet for nokre månader sidan, han sa at han raskt følte seg som en del av teamet. Han lærte av andre mens dei skreiv kode saman i staden for å f.eks sitte å lese dokumentasjon eller gjera bugfix på egen hånd. Vi reduserer trikkefaktor-problemet enda meir enn det parprogrammering vil gi i og med at vi roterer oppgaver. De lurer kanskje på kva trikkefaktor-problemet er? Viss ein person på teamet mitt biir påkjørt av trikken, er det jo litt trist, men det får heldigvis ikkje nokre konsekvenser for leveransen - for det er fleire andre som kjenner til dei oppgavene han har jobba med i det siste.

9 Ørjan: Nå er mye fint sagt om rotasjon og parprogrammering. Andre fordeler man kan høste Høyere terskel for å forstyrre Høyere terskel for å lure seg litt unna Mulig å gire ned Yrkesstolthet fremfor å ta snarveier Men når du snakker så mye om rotasjon så ser jeg jo at vi ikke løser det helt likt og at det er noe som for oss oppleves som litt vanskelig. På teamet blir samme par sitjande på samme problemet over tid. Dette kan være på grunn av store oppgaver, eierskap til kode. Det virker rett og slett mer naturlig for meg som utvikler å fortsette med samme oppgave når jeg har fått en god forståelse for problemstillingen. Hvordan oppleves dette for dere som roterer så ofte?

10 ”Det å bruke tid og krefter på
å bryte ned komplekse oppgaver er viktig. Men hvis det ikke er mulig – gjør unntak fra roteringsregelen.” Dette er jo akkurat det eg snakka om i starten. Eg syns også det var vanskelig å gi frå meg i oppgåva og å rotere så ofte. Men når me blei tvunget til å gjera det – såg me raskt fordelane med både parprogrammering og rotasjon av oppgaver og partner. Så eg trur det er eit par ting dåke burde tenka på: Det er viktig å bryte ned kompleksiteten på ei oppgave ved å bryta den ned i mindre oppgaver. Nokre ganger kan det vera nyttig å gjera litt "upfront-design" for å kunne bryte ned i små nok oppgaver... Ikkje spesielt smidig med store oppgaver. Og det er jo lov å gjera unntak fra regelen. Viss ei oppgåve er ekstra kompleks - kan eit par sitje saman i meir enn ein dag, men så snart ein av partane har fått god nok forståelse til å kunne ta den videre med ein ny person så bør de rotera partner. Enkle oppgaver – som å putte alle skjermtekster inn i resourcebundles, eller lage dto-er, er fryktelig kjedelige å gjera i par. Slike oppgaver gjer vi litt innimellom – før standup eller når parene ikkje går opp.

11 Ørjan: Hvis vi nå skal oppsummere litt hva vi mener er viktig og hvorfor så har nok de tilhørerne som nå sitter her og ikke har sovnet skjønt at vi gjerne vil fortelle at parproggramering fungerer best når man roterer utviklere i par og roterer oppgaver. Hva gir det oss å rotere oppgaver og par?

12 Fordeler for prosjektet
Teammedlemmer får det lærerikt og gøy Teamet får tidlig fordeler av parprogrammeringen og blir raskt effektive Arkitekten får glede av mer orden i koden Produkteieren får levert funksjonalitet i tide Ledelsen vil oppleve redusert risiko i forhold til fravær Håper vi nå har klart å helt eller delvis overbevise om at parprogrammering, og noe så enkelt som å bytte partner og oppgave passelig ofte gir…

13 ”Innfør parprogrammering i teamet ditt, roter partner og oppgaver – så vil kanskje du også kunne få en driv i teamet ditt som andre bare kan drømme om…” Me har veldig mykje meir å sei om kor bra det er med parprogrammering, men dåke har kanskje begynt å forstå poenget no? Prøv å innfør parprogrammering i teamet ditt, roter oppgaver og partnere - så vil kanskje du også kunne få ein god driv i teamet ditt som andre berre kan drømme om ;) Kanskje vi burde nevne her at det finnes ulemper som vi ikkje har nevnt og at vi kan fortelle om disse i åpent forum etterpå, viss det er nokon som er interessert. Parprogrammering med rotasjon av partner og oppgaver – der regler oppstår, endrer seg i temaet er så smidig at ved å tilpasse dei ulike faktorane, kan du overvinne ”nesten” alle problem som dukker opp på veien. Har tenkt litt på disse ulempene, men må innrømme at det ikkje er så lett å komme på så mangen ulember med parprogrammering. Kva om ein person på teamet ikkje er med? – Dene personen vil havne veldig utenfor fellesskapet. Kanskje det noen ganger blir vanskelig å se utover teamet fordi parprogrammeringen gjer jobbinga veldig fokusert og intenst retta mot oppgavene til teamet. I eit team som kun består av senior utviklere, vil kanskje denne måten å jobbe på gå på bekostning av den totale effektiviteten til teamet. Så vi kan vel kanskje sei at denne måten å jobbe på ikkje passer i alle sammenhenger og i alle typer team eller prosjekt – metoden vår avhenger mykje av naturen på prosjektet.