Geta

Meny NO

Hvordan jobber vi?

Geta AS er organisert i flere utviklingsteam bestående av dyktige back- og frontend utviklere med flere års erfaring innen EPiServer. Kundene våre får tildelt et utviklerteam hvor kompetansen vil bli fordelt mellom alle disse teammedlemmene. Dette gjør at prosjektgjennomføringen ikke er avhengig av enkeltpersoner i Geta, noe som er sårbart og lett kan forårsake forsinkelser i prosjektet.

Hos oss forholder kunden seg til én ansvarlig i teamet. Man vil ha én hovedutvikler/arkitekt med spesialkompetanse på kunden sin løsning i tillegg til øvrige teamdeltagere.
Hvert prosjekt sammen med kunden vil organiseres og styres gjennom hovedutvikleren.

Prosjektkoordinator vil ha overordnet ansvar for alle prosessene rundt kvalitetskontroll, metodikk og verktøy.

Prosjektmetodikk

Vi anbefaler og har god erfaring med å benytte en smidig prosjektmetodikk basert på Scrum/Kanban i våre prosjekter - som vi tilpasser til det enkelte prosjektet basert på hva som passer best for kunden og hvilke behov kunden har. Dette fastsetter vi i oppstartsmøtet sammen med dere.

En viktig del av vår smidige prosjektmetodikk i utviklingsprosjekter er en iterativ utviklingsprosess med korte arbeidsperioder på typisk 1-3 uker og en løpende tett dialog med kunden og/eller andre parter. Foran hver utviklingsperiode (sprint) prioriteres utestående oppgaver i samråd med kunden før utviklingsteamet starter med gjennomføringen. I etterkant av en sprint har kunden mulighet til å se og gjennomføre tester på det som har blitt utført i perioden. På denne måten sikrer vi at vi leverer det som er riktig for dere, med riktig kvalitet til riktig tid. Dette forutsetter tett og god dialog gjennom hele prosjektets levetid slik at man oppnår interaktivitet i utviklingen og høster lærdom av resultatet for hver arbeidsperiode.

Endringer vil alltid skje, og med en iterativ tilnærming vil vi hele tiden kunne fange opp disse endringene og få de prioritert inn i planleggingen slik at vi ender opp med en best mulig leveranse sammen. Denne metoden gjør det også enklere å fange opp fremtidige behov for kunden.

Vi vil involvere og oppdatere kunden regelmessig om status og oppfølging slik at dere har mulighet til å påvirke i prosjektet - og slik at vi sammen kan fatte beslutninger underveis om prosjektets retning.

Les mer om smidig (agile) prosjektmetodikk her: http://en.wikipedia.org/wiki/Agile_project_management

Prosjektverktøy

Geta AS benytter JIRA og Confluence som prosjektstyring- og samhandlingsverktøy for å holde tidsfrister og holde kontinuitet i prosjektet. De samme verktøyene kan benyttes gjennom hele livsløpet til løsningen. Kundene våre får tilgang til disse verktøyene der man fortløpende kan følge fremdriften i prosjektet samt legge inn endringsønsker, kommentarer osv.

Dokumentasjon av løsningen skapes og oppdateres løpende i Confluence - som igjen er tett integrert med JIRA.

Dersom kundene ønsker at andre verktøy skal benyttes avtaler vi gjerne dette med de i forkant av prosjektet.

Kvalitetssikring

For å sikre god kvalitet på våre leveranser utføres det både automatiske og manuelle tester, i tillegg til at vi oppfordrer kunden til å teste fortløpende.

Automatiske enhetstester utvikles og konfigureres fortløpende underveis i utviklingen av løsningen og har enkelt forklart som hovedhensikt å sikre at man ikke bryter eksisterende funksjonalitet ved utvikling av ny funksjonalitet. Man kan altså se på dette som utviklernes «sikkerhetsnett» mot å gjøre feil. De automatiske testene kjøres hver gang det bygges en ny versjon av løsningen og man blir varslet dersom feil blir oppdaget.

Selv med tusenvis av automatiske tester kommer man aldri helt utenom manuelle tester der man sikrer at løsningen fungerer som avtalt, at den er brukervennlig, at den fungerer i et gitt utvalg av nettlesere og at den generelt innfrir kundens krav. I sprintene gjøres denne testingen av utviklerne, men ved større leveranser og/eller en sluttleveranse settes det også ressurser som ikke har vært del av utviklingen til å teste løsningen.

Den endelige testen og aksept av leveransen gjøres av kunden. Vi oppfordrer kunden til å ha en egen rutine for testing etter hver sprint slik at feil, forbedringer etc. kommer opp så tidlig som mulig og kan tas inn i prioriteringen og planleggingen for de neste utviklingsperiodene.

Leveranser

I en iterativ utviklingsprosess skal i teorien alle utviklingsperioder ende opp med en leveranse som skal være av en slik kvalitet at den skal kunne produksjonsettes. Når rammeverket av løsningen er på plass vil dette også være praktisk mulig, selv om funksjonaliteten som skal utvikles ofte er såpass komplisert at den må spres utover flere utviklingsperioder. Dette hindrer imidlertid ikke at man kan omprioritere underveis og levere annen funksjonalitet før man fullfører det som opprinnelig var prioritert.

I vår smidige utviklingsmodell er det hele tiden kundens prioriteringer og ønsker som ligger til grunn for hvilke leveranser som gjøres når og til hvilke miljøer.

Risikostyring

Basert på det innsynet man til enhver tid har i et smidig prosjekt, uansett rolle, vil risiko ofte være enklere å oppdage og håndtere enn i mer tradisjonelle prosjekter.

I våre smidige prosjekter er risiko noe som naturlig diskuteres i planleggingsmøtene. Man kan benytte seg av en tradisjonell risikomatrise som lever gjennom hele prosjektets levetid og som oppdateres forløpende før og etter hver sprint. Hvert punkt i risikomatrisen vil ha en ansvarlig for oppfølging av den enkelte risiko.