<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=614121&amp;fmt=gif">
Kontakt oss

Skrevet av Tom Handegård | 30.11.2020

Fra få til flere utviklere – hvordan profesjonalisere når du skal vokse?

Å gå fra kaos til struktur i prosjektstyringen er ikke noe hokus-pokus. Kort fortalt bør du bruke de rette verktøyene, gjøre en grundig backlog og begynne å jobbe i sprinter.

Gjengangeren blant mange små selskaper vi møter er at de har litt å gå på når det gjelder å jobbe smart i prosjekt. Spesielt gjelder det bedrifter som går fra få til flere utviklere, der veksten gjør at gamle metoder ikke lenger fungerer så godt.

Ofte ser vi at skoen trykker mest på planlegging og rutiner, noe som igjen setter en brems på effektiviteten. Heldigvis er det ikke så mye struktur som skal til før du kan høste fruktene av innsatsen som legges ned. Det er bare å brette opp ermene og sette i gang.

cefalo-prikker-horis

Fordelene med strukturert utvikling

Det første spørsmålet du bør stille deg selv, er hva du vil oppnå med å gjøre endringer. Strukturert utviklingsmetodikk er jo ikke et mål i seg selv. Det er et verktøy som bare er nyttig hvis det hjelper deg med å oppnå andre forbedringer.

Forhåpentlig ønsker du bedre kontroll, mer transparens og en effektiv bruk av ressurser. Dette er de åpenbare fordelene med bedre prosjektstyring. Men listen stopper ikke der. Se bare på følgende effekter av å ha mer struktur på ting:

  • Sikrer god kommunikasjon
  • Unngår misforståelser
  • Tydeligere ansvarsfordeling
  • Forutsigbarhet og transparens
  • God og enkel innsikt i progresjon
  • Bedre oversikt og riktige prioriteringer
  • Utviklere som yter bedre
  • Bedre håndtering av uforutsette hendelser
  • Du unngår scopecreep
  • Skaper et klima for forbedringer
  • Selvgående team som tar fornuftige valg og opptrer mer proaktivt

Og vi kunne fortsatt en god stund til. Men hvordan skal du få den nødvendige strukturen på plass?

 

Gode verktøy for bedre prosjektstyring

Det første du bør gjøre er å velge en prosesstyringsmetode du vil følge. Det finnes store mengder litteratur tilgjengelig om ulike prosesser som fungerer godt for å styre prosjekter innen IT-utvikling.

Vi har god erfaring med, og vil anbefale deg å bruke Scrum. Dette er et smidig prosessrammeverk utviklet for å støtte kompleks produktutvikling. Det finnes flere tilbydere av kurs innenfor Scrum, og vet du ingenting fra før kan du med fordel lese denne introduksjonen til Scrum som Visma har skrevet.

En annen populær metode er Kanban. Har du ingen struktur fra før, kan Kanban være et enklere alternativ å komme i gang med.

Hovedforskjellen mellom Scrum og Kanban er at Scrum legger mer vekt på planlegging; du deler opp arbeidet i kortere tidsperioder kalt «sprinter» med klart definerte tidsfrister og mål. I Kanban fokuseres det mer på å ferdigstille én (eller noen få) oppgaver av gangen. Så fort en oppgave er ferdig, starter man på den neste oppgaven som til enhver tid er høyest prioritert.

Du kan lese mer om Scrum vs. Kanban her.

Deretter bør du velge deg et verktøy som støtter opp om styring av prosjektteam. Slik vi ser det, er det rett og slett umulig å jobbe profesjonelt uten et slikt verktøy. Gode eksempler på programvare du kan velge her er Jira og Trello. Kort fortalt er dette systemer som hjelper deg med å holde styr på alle oppgaver du måtte ha i et prosjekt eller i et team. 

Slik programvare gjør det enkelt for alle involverte å se hva andre i teamet eller i prosjektet gjør, hvordan de ligger an med et gjøremål og hvilken frist de eventuelt jobber mot. Hva som skiller de to og hvilken som passer deg, kan du lese i denne gjennomgangen av Jira vs. Trello.

 

Den viktige backloggen (eller to-do-listen om du vil)

Vær klar over at metoden og verktøyene ikke vil lykkes automatisk og på egen hånd. Det er avgjørende at du tar deg tid til å sette opp det som kalles en backlog. Det er en oversikt over alle oppgaver som ligger i prosjektet ditt, en «to-do»-liste.

I denne listen beskriver du alle oppgaver og ideer. Beskriv behov, funksjonalitet og prioritet. Ofte kan det være nyttig å la utviklerne også angi et estimat. En god backlog gjør det mulig for teamet ditt å jobbe asynkront, uten at informasjon blir borte på veien.

Det er ingen hemmelighet at hvor godt du lykkes med prosjektstyringen (og dermed prosjektet) gjerne avgjøres av hvor detaljert og nøye du har har vært i arbeidet med denne backloggen. En grundig gjennomgang av hva en backlog er, finner du her. Oppgavelisten er også bøygen for mange som ønsker å strukturere prosjektene sine bedre. De kvier seg rett og slett for å komme i gang.

 

Ikke la backloggen skremme deg

Er du en av dem som skremmes av backloggen, synes vi du skal ta det et hakk ned. Det er ikke meningen at alle oppgavene trenger å beskrives like nøye med én gang. Bare sørg for at oppgavene er nøye beskrevet før noen skal starte på dem.

Husk at en backlog er en levende materie som oppdateres, endres og detaljeres kontinuerlig.

Det ligger ingen begrensninger på hvilke oppgaver du kan ha med, og prosjekters backlog kan se helt ulike ut basert på hvem som har laget dem.

Å lage backlogen trenger altså ikke være så krevende som du kanskje tror. I sin enkleste form er det ikke noe mer enn en punktliste med oppgaver som skal gjøres. Når det først er gjort, skaper det en god forståelse av kontekst og hvor prosjektet er på vei.

 

Slik går du frem:

  • Før opp alle oppgavene, på et eller annet abstraksjonsnivå. Start med overskriftene og få med så mye som mulig, gjennom hele prosjektets levetid.
  • Når dette er gjort, kan du ta en ny runde og skrive mer detaljerte beskrivelser på de oppgavene som ligger nærmest i tid.
  • Oppgaver som ligger lenger frem i tid, kan du vente med. Disse kan detaljspesifiseres når du kommer nærmere og vet mer (bare husk å gjøre det!).



Daglige møter

Men kan daglige møter være nødvendig da, tenker du kanskje. Og svaret er – ja! Årsaken er at daglige møter er med på å sikre god kommunikasjon, de får frem en tydelig ansvarsfordeling og de legger til rette for at dere unngår misforståelser. Slike møter gjør det også enkelt å ta opp utfordringer som måtte dukke opp fra dag til dag. Uten denne daglige og direkte kontakten med teamet ditt (enten det er fysisk, eller på video), kan du ikke veilede og lytte til dem på en god nok måte. Møtene trenger ikke være lange, det kan ofte holde med ti minutter. De skal være en rask fot i bakken for å holde hverandre oppdatert og informert.

 

Jobb i sprinter

Vil du ta strukturen og profesjonaliseringen et steg lenger, vil vi anbefale at du begynner å jobbe i sprinter. En sprint er en avgrenset periode, typisk to til tre uker, der dere har som mål å ferdigstille noen av oppgavene fra backloggen. Et stort prosjekt deles opp i mindre, mer håndterbare biter. Etter hver sprint kan dere evaluere status og justere kurs.

Istedenfor å ha en lang strøm med oppgaver, får du da kortere perioder med tydelig definerte oppgaver og deadlines. Vår erfaring tilsier at dette er en måte mange utviklere liker å jobbe på. De yter mer når de får grenser å forholde seg til. Det gir styring og kontroll, men også muligheten til å nå mål.

Sørg for at dere feirer når oppgaver fullføres og mål nås underveis. Det er en viktig markering av å ha kommet et steg videre.

 

Hold retrospektive møter

Når en sprint er over, er det lurt å evaluere hva som gikk bra og hva som kunne vært gjort bedre. Det er et naturlig tidspunkt å holde det som kalles retrospektive møter, der siste periode evalueres av teamet som helhet. Poenget er å komme opp med forbedringspunkter som så prioriteres til neste periode.

Slik gjennomfører du et retrospektivt møte:

  1. Møtene trenger ikke være lange, men det er viktig at alle bidrar og kommer med sine innspill. Det legger du til rette for ved å be alle forberede to punkter som er positive og to punkter som man er misfornøyd med (eller som kan forbedres). Fokus i denne fasen bør være på prosess. Bidragene skal være skrevet ned på forhånd, for eksempel i et regneark, eller annet egnet dokument hvor alle legger inn sine kommentarer før møtet.

  2. Under selve møtet tar dere runden «rundt bordet», der alle får legge frem sine argumenter for hvorfor de har valgt som de har gjort. Her tvinger du på en måte alle til å bidra, for du ønsker at alle skal få komme til orde.

  3. Det blir som regel alltid diskusjon rundt det som tas opp. Det er en god ting! Husk god takhøyde og legg til rette for en åpen og saklig gjennomgang. 

  4. Til slutt velger dere ut to forbedringspunkter som dere tar med videre. Her plukker dere ut noen få, fordi dere mest sannsynlig ikke vil få tid til å ta alle. Da er det bedre å ha fokus på noe konkret og oppnåelig.

 

Spørsmål dere kan bruke til forberedelse:

  • Hva fungerte godt i denne perioden?
  • Hva kunne fungert bedre?
  • Hvorfor gjorde vi det på denne måten?
  • Hvordan kan vi heller gjøre det?
  • Hva gjorde at dette gikk bra?
  • Hvorfor gikk det ikke så bra?

Når du har gjort de fem tiltakene vi nevner i denne artikkelen, har du tatt fem store steg på veien mot å profesjonalisere utviklingen og prosjektstyringen din.

cefalo-prikker-horis

Er du nysgjerrig på ekstern utvikling? Vi tar gjerne en hyggelig prat med deg på telefon, møte eller video.

Snakk med oss om utviklere

Tom Handegård

Skrevet av Tom Handegård

CTO and Co-founder, Cefalo.

Hold deg oppdatert

Abonner på bloggen og få en samling av våre nyeste bloggposter på e-post.

Sign up to our blog