Arbeidsprosess

Business Online er utviklet ved å følge smidig programvare-utviklingsmetodikk

Team og interessenter

Smidige prinsipper

Smidige metodikk er et sett med prinsipper som endrer måten folk ser og utfører programvareutvikling på:

• Individer og interaksjoner over prosesser og verktøy
  • "A fool with a tool is still a fool!" - sett pris på mennesker og måten de jobber sammen på.
• Fungerende programvare over omfattende dokumentasjon
  • Fokuser på de leverte inkrementene til programvaren.
• Kundesamarbeid over kontraktsforhandlinger
  • Oppdag hva interessenter trenger og lær dem underveis, slik at endringer kan skje - Det er normalt at interessenter mislykkes i å beskrive hva de ønsker ved første forsøk.
• Reagere på endring over å følge plan
  • Endring er en realitet innen programvareutvikling som prosessen vår må gjenspeile. Det er veldig bra å ha en plan, men den må være mulig å endre ettersom situasjonen endrer seg ellers blir planen fort irrelevant.

Den venstre delen av setningene er viktigere for oss. Men ikke la dette lure deg: den høyre delen er også viktig, men i en lavere grad.

Teamets verdier

Dette er verdiene teamet vårt følger

• Fokus
  • Vi fokuserer arbeidet vårt på kun noen få ting om gangen, slik at vi kan produsere utmerket arbeid og leverer verdifulle løsninger raskere.
• Mot
  • Vi er og føler oss støttet og har flere ressurser til rådighet. Dette gir oss mot til å ta større utfordringer.
• Åpenhet
  • Vi er ikke redde for å uttrykke hvordan vi har det, hva som er på vei, og våre bekymringer slik at de kan løses så snart som mulig
• Forpliktelse
  • Vi har bedre kontroll over hva som skjer nå og i fremtiden, noe som gjør oss mer forpliktet til å lykkes.
• Respekt
  • Ved å dele suksesser og fiaskoer kommer vi til å respektere og hjelpe hverandre hver dag.

Organisasjon og målsettinger

• Siden vi tror på konstant forbedring er teamene våre faste.
  • Det betyr at hvert team har ansvar for flere produkter og har kunnskapen om produktene spredt gjennom teamet.
  • Det er opp til teamets backlog-eier å prioritere teambackloggen og indikerer hvilke produkter teamet skal jobbe med neste gang.
  • Teamet kan enkelt skaleres i tilfelle det er behov for å øke utviklingskapasiteten.
• Vi ønsker å spre den tekniske og funksjonelle kunnskapen til alle i teamet.
  • Vi ønsker at teamene våre skal være tverrfaglige.
  • Enkelt å håndtere når noen i teamet har tidsplan-begrensninger.
• Vi ønsker å tillate utvikling av synergier i hvert team.
  • Alltid på jakt etter forbedringer på våre metoder å jobbe på i hvert team.
  • Utvikling av en tett forbindelse med hverandre i teamet.
  • Lettere å opprettholde disse synergiene hvis det ikke er mye strukturelle endringer.

Roller

Teamene våre er dannet av fagfolk med klart definerte roller:

• Produkteier/Team Backlog Eier
• Teknisk prosjektleder
• Forretningsanalytiker
• Tester
• Utvikler
• Prosessmester
• Infrastruktur

Fordeler

• Konstant intern prosessforbedring i teamet.
• Opprettholde og ytterligere forbedre utviklingskapasiteten.
• Levere bedre og mer konsekvent arbeid.
• Håndtere utvikling av flere produkter samtidig.
• Tverrfaglig team – alle forstår og vet hvordan de skal utføre de fleste oppgavene.
• Ved å ikke endre teamet introduserer vi ikke støy som kan påvirke kommunikasjon og arbeidskapasitet.
• Bedre samarbeid mellom team og ledelse.

Utviklingsprosess

Basert på beviste smidige metodikker utnytter vår prosjektledelse-praksis våre evner samtidig som vi lar oss være fleksible nok til å dekke ulike kundebehov.

Vi har en veldefinert prosess som setter fokus på:

• Livssyklus
• Kommunikasjon
• Prosjektsporing
• Fordeling

Livssyklus

• Utviklingsprosessen vår består av en rekke iterasjoner;
• Hver iterasjon tilfører trinnvis verdi (funksjonalitet) til produktet;
• Små iterasjoner tillater introduksjon av endringer/fikser i en kort tidsramme – bare planlegg dem for neste iterasjon;
• Brukerhistoriene som finnes i hver iterasjon velges av teamet basert på gjeldende prioriteringer i Backlog;
• Mengden av brukerhistorier som er valgt tar hensyn til tidsrammen for hver iterasjon;
• Støtte til eksisterende produkter kan enkelt planlegges for å være en del av en iterasjon.

Våre iterasjoner er vanligvis to uker lange

Internt samarbeid

Vi implementerer tilbakemeldings-sløyfer for å sikre at alle er oppdatert på hva som skjer og for å identifisere mulige endringer og forbedringer raskere

• Kodegjennomgang: kontinuerlig, av utviklingsteamet
• Daglig Standup: Daglig
• Scrum of Scrum: Ukentlig, med prosjektteamene
• Iterasjonsplanlegging: Annenhver uke
• Backlog grooming: Annenhver uke
• Demo: På slutten av hver iterasjon
• Retrospekt: Etter hver demo

Livssyklus og kommunikasjon

Livssyklus- og kommunikasjonsfokus lar oss planlegge, samarbeide og levere verdi til produktet

Fremdrift og utrulling

• Prosjektsporing

  Vi bruker gode verktøy for å administrere arbeidet vårt. Disse lar oss:

  • Dokumentkrav som brukerhistorier.
  • Hver brukerhistorie indikerer hva brukeren trenger og hvorfor, og den er supplert med et sett med klart definerte akseptkriterier.
  • All informasjon om utvikling, kodeinnsjekking, kodegjennomgang, testing og distribusjon er vedlagt og sporbar i hver brukerhistorie.
  • Brukerhistorier er vanligvis delt inn i tekniske oppgaver slik at utviklere enkelt holder styr på hva alle gjør.
• Utrulling
  • Vi tilbyr et pre-produksjonsmiljø for iQubeS Management for å teste de forskjellige produktutgivelsene når de er klare.

Fordeler

Gjennomføringen av denne prosessen gir oss:

• Bedre forutsigbarhet
  • Vi vet hva vi jobber med nå, og hva vi skal jobbe med senere.
• Konstant tilbakemelding
  • Gjennom tilbakemeldings-sløyfen vet alle hva som skjer noe som øker åpenhet til prosjektet.
• Bedre involvering
  • Ved å holde alle informert og ansvarlig vil deltakerne føle og ha et ord på resultatet av utviklingsfasen.
• Kunden får akkurat det de trenger
  • Alle disse fordelene lar oss og iQubeS Management forstå og forbedre kravene mens vi går, slik at kunden til slutt får akkurat det de trenger.