Sådan arbejder vi

"Standarder er en forudsætning for at undersøge"

Vores laboratorium er en central del af fondens arbejde. Det er et praktikum for vores softwareudvikling.

Laboratoriet er et sted hvor håndværkerne og teknikkerne er på arbejde, og hvor vi laver software hver eneste dag, baseret på de regenerative ideer om softwareudvikling. Dermed er laboratoriet måske det aller vigtigste element i vores vidensgenerering, fordi det er her, vi omsætter vores tanker til praksis og får feedback fra virkeligheden, som vi kan bruge til at forbedre vores forståelse og vores software.

Alle kan stille opgaver til laboratoriet under forudsætning af at formålet med softwaren er i overensstemmelse med vores charter og vi har kapacitet.

I princippet er der ikke nogen begrænsninger på hvilken type opgaver vi kan tage, vi dækker bredden og har samarbejde med en række partneres og eksperter som arbejder regenerativt ligesom os selv og som vi kan tage med ind i processen. Men i praksis kan der godt opstå, kapacitets-, kompetence- eller andre ressourceudfordringer, som det kan tage noget tid for os at afdække og som derfor kan betyde at processen tager længere tid - tålmodighed er en del af den regenerative tilgang.

I laboratoriet arbejder vi under de præmisser som er beskrevet under How We Work.

Prisen for at få hjælp er ikke baseret på klassiks “time’n’material”, altså en timepris som ganges på medgået tid, uanset hvad resultatet måtte være. (Det er sådan en psykolog, advokat, revisor, cykelsmed, parterapeut eller et klassisk konsulentfirma typisk ville gøre det).

I stedet har vi to forskellige modeller for at få adgang til vores kapacitet og ekspertise, som vi kalder henholdsvis Explore og Commits:

• Explore: Kunden køber ind på en kapacitet i vores laboratorium. og så går vi ellers bare i gang. Vi arbejder tæt sammen med slutbrugerne og vi har fuld transparens i udviklingsprocessen. Vi aftaler en kapacitet på månedsbasis (100-120/md timer svarer til en fuldtidsansat udvikler) Vi logger vores arbejde, på samme måde som havde vi været ansat i kundens egen organisation og overarbejde og afspadsering kompenseres 1:1 og udligner hinanden over tid.

• Trunk commits: Kunden køber sig ind på et antal commits til main branch. eller flere features ad gangen — typisk defineret som et Vi aftaler en kadence, for eksempel et eller to deplys per dag. vi så udvikler i laboratoriet stadig i tæt kontat med slutbrugerne. Vi aftaler en pris for den funktionalitet, og så leverer vi til den pris vi har aftalt. Vi har stadig fuld transparens i udviklingsprocessen, vi logger stadig selv al vores tid, men eftersom betalingen ikke er ikke baseret på medgået tid, så vi bruger data om medgået tid til at optimere vores interne flow og vores processer.

Explore er en måde for et medlem at få adgang til vores kapacitet og vores ekspertise, uden at skulle bekymre sig om prisen for hver enkelt opgave. Det er en mere fleksibel tilgang, som giver os mulighed for at arbejde på en række forskellige opgaver og projekter, og som giver kunden mulighed for at få hjælp med det, de har brug for, når de har brug for det. Det svarer til at kunden bruger laboratoriet som sin egen udviklingsafdeling, med den fordel at man ikke behøver at op- og nedskalere som behovet ændrer sig, eller bekymre sig for om det er de rigtige kompetencer man har ansat.

I stedet har vi en prisstruktur, som medtænker er en række faktorer:

• Medlem | Ikke medlem
• Omfanget af opgaven (det er lettere for os at være effektive på store opgaver end på små — det afspejles i prisen)
• Hvor meget vi kan genbruge fra tidligere opgaver
• Hvor meget vi kan udvikle som generisk software, som kan genbruges i andre sammenhænge
• Hvor meget vi skal tilpasse softwaren til kundens specifikke behov
• Hvor meget support og vedligeholdelse kunden ønsker efter levering
• Hvor aktivt kunden involvere sig i udviklingsprocessen (mere involvering fra kundens side kan ofte føre til en mere effektiv udviklingsproces og et bedre slutprodukt, hvilket kan reducere omkostningerne)
• Typen af software der skal udvikles (nogle typer software kan være mere komplekse og kræve specialviden som vi måske ikke har internt, hvilket kan øge omkostningerne)
• hvor velegnet er opgave til at inddrage learners i udviklingsprocessen (understøtter den vores Community of Practice)
• Forskellige begrænsninger på for eksempel teknologivalg, datatilgængelighed, sikkerhedskrav eller andre faktorer som kan påvirke udviklingsprocessen og dermed omkostningerne.

Når opgaven er vurderet vil vi typisk kunne tilbyde én af to løsninger: