Nå blir det påskestemning her på Kodemaker-bloggen, med kvikklunsj, appelsiner og brettspill. Så spørs det om du får med familien på det hjemmesnekra brettspillet om software-utvikling jeg har laget.
Ja, det er riktig: Jeg er glad i å lage spill. Jeg har tidligere skrevet bloggposter fra Adventur, Kodekamp og ZombieCLJ. De bloggpostene har kanskje en klype teknisk relevans, men nå blir det bare moro, anekdoter og vrøvl.
Se på bildet under. Slik kan det altså se ut, når man har grublet, pønsket, printet, sakset, og limet i noen år. Jeg fikk til og med lært meg Adobe Illustrator.
Kort oppsummert: Spillerne styrer hvert sitt utviklingshus, og må ansette utviklere for å jobbe på features og fikse bugs. Slik kan de tiltrekke seg kunder som vil kjøpe software. Den med mest penger til slutt har vunnet.
Som du kanskje aner ut fra bildet så kan jeg ikke gå inn i alle detaljene i spillet, men jeg tenkte jeg ville dele noen artigheter som jeg selv koser meg med. Eller, i hvert fall humrer litt i skjegget av. Velkommen til et skråblikk på bransjen.
¶1. Salgsmøter
På midten av bordet ligger kunder som ingen enda har kapret. De er interesserte i forskjellige features. Kunden på bildet vil ha SSO, betalingsløsning og CMS (grå, blå, gul) med kvalitet henholdsvis 5, 4 og 3.
Når det er din tur, kan du blant annet velge å dra i et salgsmøte, for å fortelle hvor fortreffelig akkurat din software er. Andre spillere kan også dra i salgsmøte med samme kunde, og love bort andre ting.
Når kunden omsider bestemmer seg, så slår de til hos utviklingshuset som har lovet mest.
…
Ser du hvor det går galt?
Kunden slår til hos dem som har lovet mest. Det trenger ikke være noen sammenheng mellom hva du lover på salgsmøtene, og hva utviklerne faktisk har laget ferdig!
Og her er kickeren: Ettersom kundene bruker litt tid på å bestemme seg, så er dette optimal spilling.
Du har faktisk insentiv til å love mer enn du kan levere. Ikke bare unngår man at en motspiller stikker av med kunden, men kanskje rekker utviklerne å bli ferdige i mellomtiden, og man kan ta seg bedre betalt.
Så nå vet du hvorfor salgsavdelingen stadig kommer med siste-liten features som bare må på plass!
¶2. Nyttig vs riktig
Spillet skiller på hvor nyttig en feature er, og hvor riktig den er implementert. Kunder ønsker seg, og betaler, kun for nytteverdi. Problemet er, hvis det ikke er riktig implementert så vil det bli bugs. Bugs leder til misnøye, som til syvende og sist betyr at kundene kan si opp og dra til en konkurrent.
Når utviklerne jobber på en feature, så begynner de nede i venstre hjørne av
denne grid’en i bildet. Der står det 1/0
, noe som betyr at nytteverdien øker
med 1, men korrekthet står på stedet hvil.
Hvis utvikleren får arbeide videre på samme feature neste runde, så kan den klatre oppover eller til høyre i grid’en, hvor det er bedre tall. Slik vil en utvikler som får være i fred og jobbe lenge på en feature, være mer effektiv.
Problemet oppstår når en kunde plutselig slår til, og man må omrokkere halvparten av utviklerne for å levere det som har blitt lovet i salgsmøter. Da må man kanskje dra en effektiv utvikler ut av grid’en, og starte nederst i venstre hjørne igjen på en annen feature.
Kanskje noe du har opplevd?
¶3. Samarbeid og kompleksitet
Det er rom for at flere utviklere jobber på én feature av gangen, som du kan se i bildet. Problemet oppstår når man har planlagt dårlig, og utviklerne krasjer med hverandre i grid’en. Når det skjer får man fortsatt jobbet, men kompleksiteten i systemet øker.
De grå brikkene er juniorer, mens de svarte er seniorer. Seniorer kan bruke de beste feltene i grid’en uten å øke kompleksiteten – i motsetning til juniorer.
Så … dårlig planlegging, for mange utviklere på en feature av gangen, og juniorer som roter, er alle kilder til kompleksitet i systemet. Kompleksitet fører til bugs, men det er artige er:
Det gjør ingenting om du har litt bugs.
Kundene blir kanskje misfornøyde, men det skal litt til før de bytter leverandør. Hvis du bruker for mye tid på å holde kompleksiteten nede, å fikse alle bugs, ja … da vinner nok noen andre spillet.
¶4. CTO
Med fare for å fornærme halve leserskaren her, så koser jeg meg med hvordan CTO-en fungerer i spillet.
CTO-en er en egen utviklerbrikke (turkis). Fordelen med brikken er at den forbedrer samarbeid. Dersom to utviklere krasjer i grid’en hvor CTO-en jobber, så øker ikke kompleksiteten likevel.
Det morsomme er at CTO-en for alle andre formål anses som en junior.
CTO-en har rett og slett ikke klart å holde skillsa ved like. Kanskje på grunn av alle møtene.
¶5 og 6. Metodologi-kort
I tillegg til å dra i salgsmøter og utvikle features, så må man naturligvis også planlegge. Alle vet at planlegging er viktig. En av tingene man kan planlegge for i spillet, er å innføre nye metodologier. Et eksempel på det ser vi i bildet: Pair Programming.
Dette kortet gjør at to utviklere som jobber på samme feature lager riktigere kode. Det ble jo litt fint. Her er det to morsomme ting:
For det første så må parprogrammeringen planlegges to runder i forveien. Ofte når jeg spiller så viser det seg etter to runder at … vel, det passer litt dårlig akkurat nå. Det er ikke to utviklere ledig, eller så er det en hel bønsj utviklere på samme feature. Også går planleggingen min i vasken. Igjen.
Det andre morsomme er hvordan metodologier generelt fungerer: De har effekt bare den ene runden de er planlagt. Så durer man på videre uten å ha lært noe som helst.
Haha, unnskyld! Jeg sa det var et skråblikk, ikke sant?
¶7. Bespoke Features
Her har vi et annet metodologi-kort. Med Bespoke Features kan man lage litt kode på si’ som kun én kunde etterspør. De blir mer fornøyd, man får noen penger i lomma, og … kompleksiteten på kodebasen øker. Det blir mer bugs, noe som igjen går ut over alle kundene. Får håpe ingen blir så misfornøyde at de stikker.
Raske penger, da!
¶8. Krise-kort
Disse oransje kortene representerer kriser. I motsetning til metodologi-kort, så vil kriser gå ut over alle spillerne rundt bordet samtidig.
Det finnes krisekort som “Leaked Passwords” og “Zero-day Exploit”, men jeg syns jo det er litt festlig med slike kort som i eksempelet her.
PRINCE2 er en krise som gjør det første feltet i alle grid’er til 0/0
. Man får
altså ikke gjort noe som helst i starten når man begynner å jobbe på en feature,
antagelig fordi man må skrive så mye dokumentasjon.
Kriser gir også en bonus til den som spiller ut kortet. I dette tilfellet så blir en av kundene mindre misfornøyd. Det kan jo passe bra. De krever vel en form for sertifisering, da.
¶9. Conference Season
Denne krisa er litt søt, syns jeg. For utviklingshusene er “Conference Season” en liten krise, for da forsvinner plutselig alle seniorutviklerne.
Det som i praksis skjer er at man må ta dem ut av grid’en de jobber i. Runden etterpå kommer alle seniorene tilbake fra konferanse, og må starte på nytt nederst til venstre. De har tydeligvis glemt alt de holdt på med.
Det skal være sagt at kortet også gir deg mulighet til å oppgradere juniorer, og skaffe nye utviklere, så helt ute på viddene er det ikke.
¶10. Big Design Up Front
Denne krisen er helt latterlig vond å forholde seg til. Jeg pleier faktisk å ta den ut av kortstokken når nye spillere er med.
Husker du at jeg sa man måtte planlegge to runder i forveien?
Med denne krisen så øker planleggingskøen til tre kort. Da kan man nesten bare gi opp med det samme. Hvem vet hvor man er om tre runder? Ikke jeg.
“For the rest of the game, maintain a 3-card planning queue.” grøss
¶11. PHP
Igjen med fare for å fornærme leseren, så avslutter jeg med min favorittkrise: PHP. Effekten er at seniorer regnes som juniorer for alle formål.
Jeg kan ikke annet enn å humre. Det hjelper ikke å være senior hvis du må sitte og skrive PHP.
Haha, unnskyld!
Legg merke til at den som spiller ut PHP-kortet får raskt utviklet litt ekstra nytteverdi. Det passer jo fint. Litt rask nytteverdi selv først, så må alle leve gjennom krisen et par runder senere.
¶Til slutt
Det var et lite innblikk i enda en av mine sære hobbyer: å lage brettspill. Det er faktisk veldig moro: å klippe og lime, tenke og gruble, og så spille det man har laget sammen med venner. Takk for at du ble med hele veien. Håper du får en aldeles strålende påske, med eller uten hjemmelagde brettspill!