Ofte er det slik at du og kunden hadde forskjellig forståelse av hva som skulle lages. Denne forståelsen var sannsynligvis ganske identisk i begynnelsen, men manglende kommunikasjon underveis førte til antakelser som viste seg å være feil.

Kunden: “Hvordan går det?”
Du: “Det går kjempe bra! Er allerede i Sandefjord!”
Kunden: “Hva mener du med at du er i Sandefjord??”

Du satte deg i bilen din og kjørte til Kristiansand, mens kunden står og venter i Kristiansund. Hvorfor står dere på hver deres side av landet? Det som tilsynelatende var krystallklart for både deg og kunden i begynnelsen, resulterte i en skivebom av dimensjoner (ca 887 km). Hadde dere hatt en dialog underveis, ville dere mest sannsynlig kunne oppklart misforståelsen på et tidligere tidspunkt.

Selv om dette eksemplet kan virke banalt, så illustrerer det noe veldig viktig. Dersom man ikke får kontinuerlig feedback på det man driver på med, kan man fort ende opp med å kjøre i feil retning.

Veien til suksess handler om kommunikasjon med kunden. Kontinuerlig feedback sikrer at dere har felles forståelse for hvor dere skal. Det beste hadde selvfølgelig vært å ha kunden med i passasjersetet hele veien. Dette er ikke alltid mulig, men vi har noen gode erfaringer med hvordan man kan oppnå lignende nivå av kommunikasjon likevel.

Fem gode tips for å sikre at brukerhistorien blir levert som kunden forventer

1. Bruk et felles språk som både kunde og utviklere forstår.
Utviklere generelt har en tendens til å bruke veldig mye tekniske uttrykk og forkortelser. Dette er et språk kunden ikke forstår og finner frustrerende. Få vil innrømme at de ikke forstår meningen av redsel for å fremstå som mindre smarte. Språk av slik art kan også fort bli tatt for god fisk, fordi det høres “fancy” ut og kan fort føre til misforståelser. Lytt til hvordan kunden beskriver og referer til ting og forsøk å tilpasse deg språket deres. I denne sammenheng er det alltid utviklerene som må tilpasse seg domenespråket til kunden, og ikke motsatt. Likevel er det vikitig å introdusere kunden for nye konsepter som for eksempel en “hendelse”, uten å beskrive dette på et teknisk nivå. Språket er noe som du utvikler sammen med kunden over tid. Sørg for å danne basisen for dette språket allerede fra starten av prosjektet.

2. Start arbeidet ditt sammen med kunden før du begynner å skrive en eneste linje med kode.
Med dette oppnår du flere ting. For det første må du sette deg inn i problemstillingen for å i det hele tatt kunne føre en fornuftig dialog med kunden. Allerede nå får du bedre forståelse av hva som skal lages, både fordi du har tenkt over det på egenhånd, og du kanskje får svar på flere sentrale spørsmål gjennom dialog med kunden før du starter. For det andre så involverer du kunden fra starten av. Kunden vil føle det betryggende at han er involvert i prosessen. De er da i mye bedre stand til å gi deg løpende tilbakemeldinger.

3. Lag et førsteutkast med akseptansekriterier
Akseptansekriteriene definerer hva som skal til for at brukerhistorien er ferdigutviklet. Dette bør være skrevet på det felles språket som dere sammen har kommet frem til. Kriteriene bør kun inneholde den funksjonaliteten som er innenfor denne brukerhistorien. Ikke inkluder kriterier for eksisterende funksjonalitet eller funksjonalitet som er utenfor scope.

En idé kan være å formulere akseptansekriteriene dine på dette formatet:
Gitt at jeg har kr 100,-på visakortet mitt
Når jeg kjøper en øl til kr 60,- med visakortet mitt
Så skal jeg ha kr 40,- igjen på visakortet

Dette er et format fra Behavior driven development (BDD)-evangelistene som vi ikke kommer til å gå nærmere inn på i denne artikkelen.

Utviklere jobber best med konkrete eksempler, dette krever at du er presis. Når du utarbeider førsteutkastet med akseptansekriterier kommer det fort opp nye problemstillinger som man først ser når man graver seg dypere ned i detaljene. Utkastet er et godt utgangspunkt for videre diskusjon med kunden. Gjennom akseptansekriteriene dine skinner det igjennom hvordan du har oppfattet kundens behov.

4. Kall inn kunden til et møte, med utgangspunkt i førsteutkastet av akseptansekriteriene.
Selv om du forhåpentligvis har hatt kontinuerlig kommunikasjon med kunden underveis, så blir et slikt møte en “reality check”. I dette møtet vil du få kjapp tilbakemelding på hvordan “din verden” stemmer overens med “kundens verden”. Du har allerede nå satt deg godt inn i problemstillingen, og har noe konkret å diskutere med kunden. Dette gjør deg i stand til å diskutere utfordringer som er på et mer detaljert nivå enn tidligere. Kunden vil som oftest stille spørsmål rundt flere av formuleringene i akseptansekriteriene dine. Slike spørsmål tyder på at du har uttrykt noe uklart, som ofte kan føre til misforståelser. Da er det helt nødvendig å stoppe opp, tenke seg om , og omformulere. Grav deg ned i hva uklarheten dreier seg om, og omformuler akseptansekriteriet sammen. På denne måten sikrer du at kunden får det han ber om, og du får en bedre forståelse av hva som skal lages og hvilken verdi dette gir til kunden.

5. Ha en kontinuerlig feedback-loop med kunden.
Utviklerene har nå noe konkret å ta tak i. Det er fortsatt en del ting som ikke er avklart, men hovedessensen er på plass. Det dukker alltid opp nye problemstillinger etter at utviklingen har startet. Avklaringsprosessen er noe som går igjennom hele utviklingsløpet til brukerhistorien, men du har nå et godt grunnlag for å håndtere nye utfordringer som måtte oppstå. Du har dannet kommunikasjonskanalen, kunden er involvert fra starten av, og utviklerene har et klart definert sett av kriterier som de kan forholde seg til.

For å si det kort; involvér kunden så tidlig som mulig, kommunisér på et språk som dere har blitt enige om, og sørg for å få kontinuerlig feedback. Da vil man unngå mange unødvendige misforståelser og dere vil begge føle et felles eierskap til det som skal leveres. En bonuseffekt er at man kan etterprøve akseptansekriteriene når brukerhistorien er levert. Dette er mye enklere å gjøre ettersom kriteriene er noe dere har blitt enige om sammen, helt fra starten.

Dette er noen av våre erfaringer fra et av Norges største smidige prosjekter.
Hva er dine erfaringer?

Øyvind Norstein Øvregård
Finn-Robert Kristensen

Her er tre ting du kan gjøre:

Splitt opp på domene

Dette er kanskje den vanligste og enkleste måten å splitte opp brukerhistorier på. I domenet ditt vil du gjerne finne flere type kategorier av for eksempel produkter. Disse er ideelle å dele opp historiene dine på. La oss tenke oss et forsikringsselskap som tilbyr en rekke forskjellige forsikringsprodukter. Mye av tiden går til å behandle forsikringssaker og man skal lage et nytt system for å forbedre saksbehandlingstiden.

Eksempel:
Som en saksbehandler
Ønsker jeg å behandle en forsikringssak
Slik at ..

Hva slags type forsikring er dette? Er det en skadeforsikring eller kanskje en livsforsikring? Her kan vi dele brukerhistorien opp på de forskjellige produktkategoriene.

Som en saksbehandler,
Ønsker jeg å behandle en skadeforsikringssak,
Slik at..

Hvis 70% av alle forsikringssaker er skadeforsikring vil jeg anta at denne vil ha en høyere prioritet enn en livsforsikringssak som kanskje gjelder 5% av alle sakene. Dette hjelper deg til å prioritere brukerhistoriene dine bedre.

Splitt opp på operasjon

Mange brukerhistorier handler om å skrive eller lese noe data. Dette kan vi dele opp i fire operasjoner: opprett, oppdater, slett og les.

Som en administrator,
Ønsker jeg å administrere brukere
Slik at jeg har kontroll på hvem som har tilgang til systemet

Etter samtaler med administratoren finner vi ut at han har behov for å opprette, endre og slettte brukere. Og ikke minst vise en brukerprofil som da blir les operasjonen. Du har nå mulighet til å dele opp en brukerhistorien i fire nye brukerhistorier.

Eksempel på å opprette:
Som en administrator,
Ønsker jeg å opprette en ny bruker
Slik at jeg enkelt kan gi nye brukere tilgang

Splitt opp på roller

Når vi diskuterer en brukerhistorie handler den som oftest om flere type brukere. Det kan være alt fra brukere som skal ha begrenset tilgang til brukere som bruker funksjonaliteten mer enn andre. Det kan lønne seg å identifisere hva slags type brukere som skal bruke funksjonaliteten og ut i fra dette bryte opp historien som beskriver hvem disse brukerene er og hva de trenger å kunne gjøre.

Som en kunde,
Ønsker jeg å angi en leveringsadresse,
Slik at …

Du har sikkert mange forskjellig typer kunder. Noen er kanskje innom daglig? Kanskje har du noen gode kunder som du ønsker å gjøre brukeropplevelsen bedre for?

Som en jevnlig kunde,
Ønsker jeg å kunne velge en leveringsadresse fra mine tidligere ordre,
Slik at jeg sparer tid på å fylle ut adressen min hver gang

Konklusjon

Ved å bryte ned historiene så får du noe som er enklere å prioritere innenfor en leveranse. Bryter du ned historiene dine vil du også ha mulighet til å implementere den viktigste funksjonaliteten først og unngå å bruke tid på å implementere funksjonalitet som sjelden blir brukt.

Her var tre eksempler på hvordan du kan bryte ned brukerhistoriene dine. Det er ikke alle brukerhistorier dette vil fungere på, men stort sett de fleste av dem.

Hvilke teknikker bruker du på å bruker historiene dine?

Rutinepreget evaluering
Å evaluere seg selv er selvsagt viktig også i andre prosesser enn Scrum. Det å stadig forbedre seg, for å kunne jobbe mer effektivt, levere bedre kvalitet og trives bedre som team, er en nøkkelfaktor for suksess i de fleste prosjekter. Dessverre kan retrospektivmøter etterhvert bli rutinepregede; En aktivitet man gjør iterasjon etter iterasjon, uten egentlig å få fram de tingene som betyr noe, eller tenke nytt om temaer som går igjen gang etter gang. Da kan det ofte hjelpe å bryte opp mønstrene og gjøre noe nytt, for å skape variasjon og nytt engasjement rundt retrospektivet.

Her er et referat fra et retrospektiv jeg nylig hadde sammen med teamet jeg er Scrum Master på. Kanskje kan disse øvelsene inspirere deg til å skape ny glød neste gang du skal delta på et retrospektiv.

Første øvelse: Tidslinja
Først tegnet vi opp ei tidslinje som illustrerte de tre ukene som iterasjonen hadde vart. Det var ei rett linje med helgene og andre fridager markert. På denne linja tegnet vi inn viktige hendelser. For eksempel måtte vi i slutten av første uke endre løsningsbeskrivelsen på flere av oppgavene på iterasjonskøen, fordi de var basert på en forutsetning som viste seg å være feil. I uke to måtte vi gjøre noen uplanlagte feilrettinger på en tidligere leveranse, og i uke tre fikk vi et nytt medlem på teamet.

Dette er noen eksempler på ting som kan tegnes inn på tidslinja. Det er ingen regler for hva som er riktig eller feil å tegne inn. Stort og smått kan tas med. Poenget med denne øvelsen er rett og slett å friske opp hukommelsen til teamet. Vi hjelper hverandre med å huske hva vi skal evaluere.

Andre øvelse: Happygraf
Under tidslinja fikk så hvert teammedlem anledning til å tegne sin Happygraf. En Happygraf er en kurve som viser hvor fornøyd/glad eller misfornøyd vedkommende har vært i løpet av iterasjonen. Jo høyere kurve, jo mer fornøyd er du. Skalaen bestemmer dere selv. Dette er en morsom måte å uttrykke hvordan du har hatt det de siste tre ukene. Og det gir en fin innfallsvinkel til å kommunisere om følelser, uten å bruke ord.

Tredje øvelse: Stikkordslotto
I den siste øvelsen fikk hvert teammedlem utdelt grønne og røde lapper. På de grønne lappene skrev vi ting som hadde fungert godt i iterasjonen, ting vi ville fortsette med å gjøre. På de røde lappene skrev vi forbedringspunkter, ønsker om endring. Her brukte vi stikkordsform, slik at vi bare skrev et ord eller et uttrykk på hver lapp. Setninger var forbudt.

Deretter samlet vi inn alle lappene og blandet dem sammen. De grønne lappene i en haug, og de røde i en annen. Så trakk vi etter tur en og en lapp fra en bunke, og leste stikkordet på den høyt. (Fikk vi en av våre egne lapper la vi den tilbake og trakk en ny.) Den som trakk en lapp måtte prøve å tolke hva stikkordet betydde. Da kunne hun gjerne bruke sine egne erfaringer fra iterasjonen til å forklare hva vedkommende hadde ment, og hva hun selv ville legge i ordet.

Etter at hun hadde sagt hva hun tenkte stikkordet betydde, skulle den som hadde skrevet lappen forklare hva han egentlig hadde ment. På denne måten fikk vi minst to forskjellige vinklinger på samme tema, og svært ofte gode diskusjoner som følge av det. En av oss hadde samtidig rolle som sekretær, og førte et referat av hva som ble sagt.

Tiltak og ambisjoner
Sammen fikk disse tre øvelsene fram flere lærdommer fra de siste ukene. Vi diskuterte flere vinklinger enn vi tidligere har gjort på samme tema, og gravde dypere i noen enkeltsaker. Til sammen brukte vi ca to timer på øvelsene. Vi kombinerte det med lunch, og hadde kjøpt inn mat.

I begynnelsen av den påfølgende iterasjonen tok vi en gjennomgang av referatet fra retrospektivet. Vi valgte ut de tre viktigste punktene hvor vi ønsket å sette oss konkrete mål for forbedring. Vi ble enige om tiltak og ambisjoner for hvilke resultater vi ønsket å oppnå. Denne gjennomgangen brukte vi ca en time på.

Dine erfaringer
Hvilke erfaringer har du med retrospektiver? Har du opplevd noe som har fungert spesielt godt, eller har du tips til øvelser som er morsomme og gir gode resultater?

En code kata er en enkel øvelse for å skjerpe programmeringsferdighetene dine. Det vil si – du trener bare problemløsning den første gangen du utfører øvelsen. Så gjentar du øvelsen, om og om igjen, til det sitter i fingerspissene. Og hver gang prøver du å gjøre det litt kjappere. Hensikten er å trene hastighet, teknikk og verktøy.

I klippet under lager jeg en variant av Minesweeper kataen i JavaScript.

(Kjør den i fullscreen for å se koden mer tydelig)

Merk: Jeg bruker testdrevet utvikling gjennom det meste av prosessen. På slutten dropper jeg TDD når jeg gjør det visuelle og selve spillmekanikken. Dette kunne også testes fra kode, men jeg droppet det for å gjøre den mer artig å se på.

Du kan se på koden i github-kontoen min. Hver commit er en separat gjennomkjøring av øvelsen fra scratch.

Jeg brukte følgende libraries og verktøy:

• Underscore.js
• jQuery
• Grid.js
• clAutotest
• TextMate

I den intensive godkjenningsperioden vi har vært gjennom, ble rollen ”Loggvakt” opprettet. Rollen har holdt løpende oppsyn med serverlogger, gjort logganalyse og ytt bistand til Delprosjekt Test for preanalyse av feil som rapporteres. Bemanning av rollen har gått på rundgang i prosjektet.

Intet kunne ha gledet meg mer! Jeg selv var så heldig å få sitte loggvakt ”hjemme hos” Delprosjekt Test – og det to dager på rad attpåtil! Og det var da refleksjonene kom… Vi tar’n like godt på engelsk

During test intensive periods – engage your project members on “log surveillance duty”!

The person on duty has the chance of becoming a real detective! He or she should tail essential server logs continuously, analyse them and initiate proper action when e.g. specific stacktraces, log statements, log sequences or log-patterns appear. The log surveillance duty role should also take part in early analysis of important bug reports so that they can be handed over to relevant teams as fast as possible.

Using the log surveillance duty as one of several “bug hunt approaches”, the project may experience that bugs are caught earlier. In addition, without the log surveillance duty role, some of these bugs would not have been reported at all. You’ll see the effect of this during free testing in particular.

Imagine this “happy day situation” in your project:

“ALERT – we have a situation! Log statement GOOD_STUFF in the jBoss log”!

“Ta-ta-raaaa! Who did a search for GOOD_STUFF just a couple of minutes ago and got an error message? Ah-so you were the one! Grrrreat! Oh.. so – you’re – used to ignoring this error message- are you – ok…Please tell us when such messages appear, will you? It’s of great value! But now … What was your scenario again? And the five steps preceeding your scenario? Can you rerun it, please…..? Thanks! …..Bingoooo!! The GOOD_STUFF_BUG has been reproduced, it has been trapped! Juppie!! My hero tester! Could you report that bug for me, please?”

When assigning resources to the log surveillance duty role, people with different interests, orientations and skills should be motivated to take part! Experience the incredible opportunities just waiting to be used – to increase the over time quality of the system being built!

• One day – call a JEE architect, a senior developer for duty -
• The day after that – a user scenario oriented person –
• The next day a developer with DB-expertise -
• A junior developer –
• A technically oriented senior tester -
• And then a “usability minded” one –

Keep on rolling – keep on changing – keep on building system quality mind set – keep on spreading system understanding – keep on….

Don’t wait! Just do it! Market the log surveillance duty role and motivate your project members to take part! Prepare yourself to be called!

… I’ll bet you’ll take on new habits after you organized your first round – or the first time you participated – I’m sure!

So, get on with it! Good luck! 

P.S:

Hvis du har lest min blogg fra 04/10/2010 og du allerede er på god vei til å bli en Buglock Holmes i prosjektet ditt, ser du nok at på loggvakta får du brukt alt det du har blitt vant til å gjøre som Buglock!

D.S.

• Ha en grov oversikt over områder de ulike teamene i prosjektet jobber med…
• Kjenn rimelig godt til hva produktkøen for prosjektleveransen inneholder…
• Vit hva teamet ditt og hva andre team i prosjektet har levert …
• Husk at det er nyttig å ha god oversikt over hvilke deler av produktkøen som ikke inngår i leveransen …
• Sørg for at ørene dine vokser seg store og sterke! Vær nysgjerrig! Snus rundt!
• Prøv å snappe opp ting som foregår hos naboteamet, ved kaffeautomaten…
• Hold øye med serverloggene i integrasjonstestmiljøet for prosjektet…
• Hold en rimelig god og helst løpende oversikt over hvilke feil som meldes inn i feilrapporteringssystemet i testintensive perioder …
• Lær deg å huske nøkkelord og nøkkelsituasjoner, designdiskusjoner ved tavla og møter eller samtaler der viktige forståelser eller avklaringer ble skapt…
• Husk situasjoner der folk var svært uenige om deler av løsningen…
• Lær deg å huske situasjoner der man faktisk kom til enighet…
• Bli pådriver for at viktige avklaringer og omforente tolkninger styres inn i klare krav, testbetingelser, skjermskisser, flytskjemaer, figurer etc. …
• Bli pådriver for at de klare kravene etc. forstås på samme måte – spesielt av de som var uenige / ikke forstod hverandre…
• Innse selv og hjelp ulike interessenter til å forstå at ikke alle uenigheter kan forenes…
• Erkjenn at uansett hvor godt vi dokumenterer avklaringer, kan vi forvente at der ulike interessenter var uenige, vil diskusjoner dukke opp igjen senere i prosjektets liv, f.eks. når systemet leveres til test eller til produksjon…

Tren deg noen av disse teknikkene! Da vil du etter hvert bygge en god oversikt over hele systemet dere leverer! Du kan ta aktive grep i forhold til vanskelige feilfloker og du vil forstå hvordan de ulike feilene/manglene henger sammen med hverandre.

Lykke til, Buglock!

Dette er et eksempel på hvordan kommunikasjon erstatter planlegging. Slik kan det også være i prosjekter. Man må være enige om hva målet med prosjektet er, men dersom man kommuniserer underveis, kan de nøyaktige midlene bli til underveis.

Nesten daglig sitt-ned-møte

Mange bruker “daglige stå-opp møter” i Scrum. Teamet står rundt tavla og koordinerer utførte, pågående og kommende oppgaver. På mitt forrige prosjekt ble vi inspirert av en blogpost til å utvide stå-opp møtet med et “nesten daglig sitt-ned møte” når det var hensiktsmessig.

På stå-opp møtet gikk vi gjennom hvilke oppgaver utviklerne hadde gjort ferdig, og hvilke oppgaver produkteier hadde sett gjennom. Etter stå-opp møtet satt produkteieren og utviklerne seg sammen og gikk inn i detaljene:

• Produkteier hadde med seg en liste med forbedringer fra tidligere funksjoner. De forbedringene som tok under 2 minutter å utføre gjorde utvikleren der og da. Oppgaver som ville ta litt lengre tid noterte utvikleren seg. Oppgaver som var for omfattende ble tatt inn i fremtidige planer.
• Utvikleren viste produkteieren de tingene som var “ferdige” i går. Produkteieren kom med direkte feedback der og da, og noterte seg hva han skulle seg gjennom på egen hånd.
• Produkteieren gikk gjennom detaljene for funksjonalitet som utvikleren skulle starte på og besvarte spørsmål

“Jeg vet det når jeg ser det”

“Measure twice, cut once” er det noen som sier. Men på utviklingsprosjekter er det slettes ikke sikkert at det å beskrive noe ekstra grundig forbedrer sjansene for å lykkes. De eneste gangene jeg har opplevd at en kunde ikke kommer med tilbakemelding første gang hun ser produktet er når jeg har en kunde som egentlig ikke bryr seg. Eller når jeg hadde brukt alt for lang tid på å dekke alle eventualiteter, inkludert de som ikke var kostnadeffektive.

I et vellykket prosjekt vil prøving, visning og tilpasning være normalen. Jo tidligere prosjektet får tilbakemeldingene, desto bedre og billigere blir prosjektet. Og jo mer nøyaktige planer vi legger i prosjektet, desto vanskeligere blir det å tilpasse seg tilbakemeldingene.

Felles mål, daglig kontakt, daglig tilbakemelding og daglig tilpasning vinner over grundige planer.

Har du fått med deg at Smidig 2010 arrangeres 16.-17. November på Radisson BLU, Holberg plass i Oslo? Konferansen har åpnet for foredrag. Early bird prisen på billetter varer KUN TIL TORSDAG, så det gjelder å bestemme seg fort!

Opplev vårt unike format, med over 70 lyntaler og 100 diskusjonsgrupper! Smidigkonferansen er den årlige nasjonale hendelsen som samler mennesker fra alle typer roller i IT-bransjen; prosjektledere, produkteiere, utviklere, bedriftsledere og testere og flere.

• Meld deg på som deltager eller foredragsholder
• Meld deg på LinkedIn-gruppa vår
• Meld deg på mailingslista for de som er interessert i Smidig 2010

Jeg har fått dilla på dynamiske programmeringsspråk (JavaScript, Ruby, Lisp, med flere) i det siste. Et av fellestrekkene ved slike språk er at de lar deg programmere interaktivt. Vet du ikke hva interaktiv programmering er? Flott, da har du kommet til riktig artikkel!

Ideen bak er ganske enkel, men jeg tror det er enklere å vise hva det er først, istedet for å skrive masse forklarende tekst. Her er et eksempel, demonstrert med IRB (Interactive Ruby):

Hva skjer her?

Vel, jeg skriver ekstremt grunnleggende Ruby-kode. Men se hva som skjer underveis. Hver Ruby-setning jeg skriver inn blir evaluert og kjørt av systemet. Resultatet spyttes tilbake på kommandolinja. Systemet husker hva jeg gjør. Jeg definerer variabler og funksjoner. Jeg kan bruke og bygge videre på dem, og jeg får umiddelbar feedback på alt jeg gjør. Og jeg slipper å kompilere eller restarte koden min hver gang jeg prøver noe nytt.

Den vanlige prosessen vår for systemutvikling er som et stålverk. Vi lager en støpeform (skriver kode i en IDE). Så støper vi en klump stål (kompilering/restart). Dersom stålklumpen ikke har riktig form, så er det tilbake til tegnebordet for å justere støpeformen. Denne feedback-løkka er mye raskere enn før takket være raskere kompilering, bedre maskiner og enhetstesting – men vi kaster likevel bort en del tid når vi løper frem og tilbake på denne måten.

Interaktiv programmering derimot er mer som å jobbe med leire. Vi arbeider med samme stykke materiale kontinuerlig. Vi klatter på litt kode, ser hvordan det ser ut. Tar vekk ting, bytter ut, former, eksperimenterer.

Dette er ikke en erstatning for hvordan vi vanligvis arbeider, men mer et nyttig tilbehør. Du bygger ikke en produksjonsbil med leire, men det er mye lettere å lage f.eks en design-prototype med leire enn med stål. På samme måte kan interaktiv programmering være et bra hjelpemiddel og supplement for seriøs systemutvikling.

Helt konkret: hvorfor er interaktiv programmering nyttig?

• Du arbeider raskere, fordi feedback-løkka er kortere.
• Du slipper unna med mindre kode, fordi du bruker mindre tid på å bygge infrastruktur og “boilerplate”.

Mer komplisert er det ikke. Jeg mistenker imidlertid at det ene bruksområdet ovenfor ikke overbeviser helt. Jeg skal derfor vise flere eksempler, og du kan tenke over hvordan disse teknikkene passer inn i din egen verktøykasse.

Jeg bruker jevnlig interaktiv programmering til følgende:

• Utforsking og læring
• Grensesnitt mot backend-system
• Frontend-utvikling og prototyping

Utforsking og læring har vi allerede sett via IRB-klippet over. Neste eksempel er et interaktiv programmering som grensesnitt mot et kjørende system – i dette tilfellet en Ruby on Rails-applikasjon.

I filmklippet som følger lenger ned starter jeg et interaktivt konsoll på en lokal testserver. Der har jeg tilgang til det samme api’et, databasekoblinger etc som forretningslogikken i backenden av systemet mitt. Dette lar meg gå inn i en kjørende applikasjon og prøve ut nye ting, trekke ut informasjon eller gjøre små oppdateringer - mens systemet fremdeles kjører.

Man kan bruke dette konsollet til system-administrasjon i et produksjonssystem: istedet for å bygge tidkrevende web-admin-funksjonalitet i systemet ditt, så kan du la døra stå åpen for å ta de mer sjeldne oppgavene direkte i det interaktive konsollet. Bygg eventuelt web-UI for manglende ting dersom du ender med å gjøre samme oppgave om og om igjen på kommandolinja.

Dette shellet kan også brukes under utviklingsløpet for å se “hvordan ting arter seg” før man velger å forfølge noen bestemt løsningsretning med unit-tester, web-grensesnitt osv osv.

La oss flytte oss opp til frontend-utvikling. Når vi utvikler web-grensesnitt så har vi et annet interaktivt miljø vi kan bruke: Firebug-konsollet. Her er en liten demonstrasjon.

Dette var et veldig enkelt eksempel. Jeg bruker imidlertid samme teknikker når jeg jobber med mer komplekse webapplikasjoner: da bruker jeg hyppig konsollet for å prøve ut ting “live”. Metodikker som f.eks testdrevet utvikling er flott for backend-utvikling, men i visuell/frontend-utvikling er det ofte vanskelig å lage programmatiske tester siden man ikke helt vet hvordan ting kommer til å se ut og oppføre seg i nettleseren. Kanskje vet du ikke engang helt “hva du leter etter” på forhånd? Da er det fint å kunne prøve seg fram litt før man skriver for mye kode.

Nå vet jeg hva du tenker. “Men Thomas, jeg har ikke lyst å sitte og skrive kode rett inn i disse kommandolinje-greiene. Jeg liker editoren min mye bedre!” Jeg forstår den innvendingen. Du kan eventuelt skrive koden i editoren og manuelt lime den inn på kommandolinja, men det er blir fort litt knotete. Vi har mer lyst til å arbeide i en skikkelig IDE, og sende kode derfra til det interaktive miljøet. Vi skal se på et eksempel på slik arbeidsflyt i et språk som heter Clojure.

Clojure er et ungt, lovende programmeringsspråk. Det er bare noen år gammelt, men er bygget på moden teknologi. Clojure er implementert i Java, snakker pent med Java-biblioteker, og basert på LISP (en over 50 år gammel dialekt av programmeringsspråk). Det vi hittil har kalt “interaktive konsoller” blir ofte kalt Read-Eval-Print-Loops (REPL). Dette utrykket kommer opprinnelig fra LISP, som har hatt slike verktøy (og kultur for å bruke dem aktivt) i mange år.

La oss se på et eksempel i Clojure. Jeg holder meg i editoren min, og sender funksjoner og kommandoer til REPL-prosessen rett fra editoren min. I dette tilfellet bruker jeg dette til å jobbe smidig med 3d-grafikk (jeg er veldig uerfaren på dette området, og trenger derfor umiddelbar feedback på alt jeg gjør). Klippet under starter med å demonstrere helt grunnleggende ting, så tar vi steget opp til grafikk-arbeid. Mot slutten implementerer jeg rendering av et veldig enkelt  Tetris-spill.

Hva har vi sett så langt?

Interaktiv programmering gir deg rask feedback. Det lar deg jobbe hurtigere, skrive mindre kode, lære og utforske, snakke direkte med kjørende systemer, og gjøre effektiv prototyping og visuell utvikling.

Nå tenker du kanskje: “jeg arbeider med Java til daglig, hvordan kan jeg bruke disse greiene til noe nyttig?” Vel, alle disse teknikkene kan brukes sammen med Java-kode. Ruby kan kjøres på Java: JRuby er en moden platform som snakker pent sammen med Java-komponenter. JavaScript likeså: du kan enkelt kjøre JavaScript på serversiden som et interaktivt skall rundt applikasjonen din. Clojure er allerede bygd i, og beregnet for bruk sammen med, vanlig Java (3D-eksemplet ovenfor bruker allerede et Java-API for OpenGL-grafikk).

Det er derfor ikke mye som skal til for å få slike interaktive skall rundt din egen applikasjon. Kan du lukte mulighetene her?

Til slutt vil jeg gjerne at du tar en kikk på filmklippene under. De er eksempler på s.k. Livecoding, en aktivitet som ligger i skjæringspunktet mellom programmering og performance-kunst. Det som skjer i klippene under er at utvikleren koder opp improviserte algoritmer for lyd og musikk live foran publikum. Kanskje ikke nyttig umiddelbart nyttig for deg og meg, men det er et interessant eksempel på interaktiv programmering tatt til sin ytterste konsekvens.

Referanser:

A list of REPL environments

Demystifying IRB commands (interactive Ruby)

Secrets of the Rails Console Ninjas

The Firebug Console Panel

Clojure.org: ‘Getting started’

in which are found tricks of the trade concerning clojure authorship

Penumbra OpenGL framework: ‘Getting started’

Impromptu livecoding environment introduction

Andrew Sorenson livecoding videos

Det siste halve året eller så har jeg gått å gledet og gruet meg over dette tilbudet. Og det har slått meg: Å skrive et tilbud er som å forelske seg.

Først blir man litt kjent med kunden og kundens problem. Noen fanger interessen, og man får lyst til å vite alt om problemet. Man spør og graver. Om man ikke får snakke med kunden (og det får man ofte ikke i denne fasen), så snakker man med kolleger og venner som naturligvis ikke har noe svar: “Tror du at det er sånn? Tror du at dette er forklaringen på hvorfor det som de ba om var litt pussig? Tror du at de vil være interessert i dette forslaget?”

Til slutt bestemmer man seg for å satse alt. Søvnløse netter går mens man forsøker å fremstille seg attraktiv for den andre parten. Man forsøker å finne hva den andre parten har lyst til. Og noen ganger må man våge å si noe de ikke vil, men egentlig trenger å høre. Så leverer man et tilbud. Man må tørre å legge alle følelsene sine i tilbudet, fullt vitende om at man kan bli avvist. Den som intet våger, intet vinner.

Så kommer forhandlingene. Den andre parten føler seg attråverdig. De har mange beilere. Man snakker om en mulig fremtid sammen, men den andre parten vil ikke forplikte seg. Man tenker i sitt stille sinn “men jeg liker deg, liker ikke du meg, da?” Men man våger naturligvis ikke å si det.

Og til slutt sier de “ja”. Man er klar til å knytte knuten.

Og nå starter deg egentlig jobben. Jeg gleder meg.

Jeg skal fortelle deg hvorfor du bør lære deg et s.k. scriptspråk. Scriptspråk har andre styrker enn Java og C#, og tilfører allsidighet og produktivitet til verktøyskuffen din. En kompetent håndtverker bruker mer enn hammer på jobb: skrutrekker, meisel og knipetang må også med.

Steve Yegge skrev for noen år siden en glimrende artikkel om hvordan han skiller gode utviklere fra svakere kandidater under jobbintervjuer ^[1]. Et av poengene hans er at mange utviklere har en akilles-hel: det ene språket de mestrer er ikke ideellt til alle situasjoner. De er “one trick ponies”.

Her er et intervjuspørsmål som Yegge bruker til å teste kandidater:

Last year my team had to remove all the phone numbers from 50,000
Amazon web page templates, since many of the numbers were no longer in
service, and we also wanted to route all customer contacts through a
single page.

Let’s say you’re on my team, and we have to identify the pages having
probable U.S. phone numbers in them. To simplify the problem slightly,
assume we have 50,000 HTML files in a Unix directory tree, under a
directory called “/website”. We have 2 days to get a list of file
paths to the editorial staff. You need to give me a list of the .html
files in this directory tree that appear to contain phone numbers in
the following two formats: (xxx) xxx-xxxx and xxx-xxx-xxxx.

Hvordan ville du løse dette problemet? Hint: Java og C# er ikke førstevalget til Steve, ei heller mitt. Du KAN løse dette og mange lignende problemer i Java eller C#, men et scriptspråk lar deg løse problemet raskere og mer elegant.

Så hva er scriptspråk og hvorfor er de så nyttige? Jeg definerer kort og godt disse til å være Ruby, Python, og Perl. Alle tre er modne, populære språk. Det betyr ikke så mye hvilket av dem du lærer først: alle sammen deler de fleste av følgende styrker:

• Førsteklasses støtte for å manipulere tekster og filer.
• Fungerer bra sammen med kommandolinje-verktøy og shellscripting, spesielt på unix-systemer.
• Enkle å komme igang med. Vanligvis preinstallert på Unix, Linux og OS X-systemer.
• Gode til proof of concepts og prototyper. Passer bra til å rask iterere frem og demonstrere konsepter.
• Ypperlige til å automatisere oppgaver (f.eks scripting av operativsystemer, applikasjoner, byggeprosesser).
• Er gjerne dynamisk typede språk, noe som lar deg bruke mindre tid på syntax og mer tid på selve oppgaven du skal løse. ^[2]
• Kan kjøre oppå, eller sammen med, de tyngre platformspråkene (se JRuby, IronRuby). Best of both worlds!
• Gir deg et nytt perspektiv på platformer og språk du allerede mestrer. Det er alltid nyttig å utvide horisontene sine! ^[3]

Høres dette nyttig ut? Har du lyst til å lære mer? En god måte å komme igang på kan være å lese denne boka:

eller denne:

Sett deg så ned med et konkret prosjekt. Finn f.eks en “tidstyv” i hverdagen din – en rutine som kan automatiseres. Lag et script som løser problemet ditt.

Vips: fremtidig tid spart, og du har begynt å legge et nytt, kraftig verktøy i reportoaret ditt!

Referanser:

1) Yegges artikkel om intervju-spørsmål
2) Yegge om styrkene til scriptspråk/dynamiske språk (video)
3) Robert “Uncle Bob” Martin om hvorfor du bør lære nye språk (video)

Hvorfor gjør vi IT-investeringer? Det handler om å redusere komplekse problemer til meningsfylte oppgaver som mennesker kan fullføre.

Jeg ønsker å fokusere på utvikling av programvare (løsninger, pakkeprodukter, osv) og hvilken verdi programvare har for våre brukere. Å bygge programvare er en av flere viktige funksjoner som vi gjør hos Steria, og det er tusenvis av andre som også bygger programvare for å løse utfordringer.

Undersøkelser har vist at vi ikke har hatt særlig forbedring i suksessraten i utviklingsprosjekter. Bransjen har ca. 30% suksess i prosjekter som starter opp, og slik har det vært siden 1996 i følge Standard Group (CHAOS Report). Hvorvidt dette er representativt for det norske markedet er ukjent, men egne erfaringer fra Norge tilsier at det er en betraktelig høyere andel prosjekter med suksess her i landet, mye takket være smidige teknikker og prosesser.

Programvarens lov

I henhold til David S. Platts 3 lover om programvare, har programvaren vi bygger i seg selv ingen verdi. Det har liten betydning hvor teknisk bra kildekoden til et program er, det er kun vår egen mor som bryr seg om slikt.

Platts 3 lover sier:

1. Programvare har ingen verdi i seg selv. Den eneste verdien programvare har er gleden den gir til brukeren.
2. Programvaren kan øke brukerens glede på en av to måter. Den kan hjelpe brukeren å fullføre en ønsket oppgave, eller den kan gi en god opplevelse. Eksempelvis hjelper Outlook med å lese og skrive epost, mens HALO på Xbox 360 gir deg en god opplevelse som er underholdende.
3. Brukeren skal ikke tenke på programvaren. Det viktigste er innholdet og oppgaven, ikke programvaren i seg selv.

Målet med programvare bør alltid være å redusere komplekse problemer til enkle oppgaver. Enkle oppgaver som mennesker kan utføre, uten at det krever mye tankearbeid. Desto mindre en bruker må tenke, desto mer glad og produktiv vil han bli.

Tenke enkelt

Når vi har et komplekst problem vi ønsker å løse, hvilke mekanismer pleier vi å benytte for å løse dem? Når vi ser på programvaren som har blitt utviklet opp igjennom årene, er det ganske klart at vi ikke tenker på å gjøre ting enkelt.

Vår forståelse av komplekse problemer øker desto mer vi jobber med dem. Men vi har problemer med å komme opp med enkle løsninger. Altfor ofte lager vi kompliserte løsninger for komplekse problemer. Dette må vi forsøke å unngå, for det er hovedårsaken til at utviklingsprosjekter feiler.

Vi må sammen begynne å tenke enklere. Vi må sammen utforske hvordan vi kan redusere komplekse detaljer i et løsningsdesign, helt til vi sitter igjen med et design som er så enkelt som overhodet mulig og fortsatt gir verdi til brukerne.

Vårt mål bør være: Lage en enklest mulig arkitektur.

Det er selvsagt mange årsaker hvorfor noe som starter enkelt, fort blir komplisert. En viktig faktor er mengden av funksjonalitet i en løsning. Robert L. Glass  skriver i boka “Facts and Fallacies of Software Engineering” at 25% økt funksjonalitet øker kompleksiteten med 100%.

Neste gang du står ovenfor et problem som noen ønsker løst ved hjelp av programvare, start med å tenke over brukerne og hvordan du kan øke deres glede. Deretter reduserer kompleksiteten i løsningsdesignet til du oppnår det enkleste designet som er mulig som fortsatt oppnår målet: Gjøre brukerne glade!

(Se mitt innlegg om løsningsarkitektur på MSDN Live for mer detaljer om dette emnet)

Noen av oss kjører strikt, metodisk testdrevet utvikling. Andre bruker bare automatiserte tester nå og da som sikkerhetsnett for å unngå regress-feil. Hvor ofte fyrer du selv av testene dine? Kjører du testsuiten din en gang i ny og ne, eller strikt for hver metode du implementerer?

Jeg liker å kjøre testene mine ofte mens jeg arbeider. Det jeg liker enda bedre er å la utviklingsmiljøet mitt kjøre dem for meg, automatisk. Poenget med yrket vårt er jo nettopp å automatisere og effektivisere arbeidsprosesser – dette forsøker jeg å gjøre også med mine egne rutiner og verktøy. La oss se hvordan vi kan få til dette.

Mange av oss bruker allerede Continuous Integration for å oppdage feil i den felles kodebasen. Personlig autotesting er det neste, logiske steget: enhetstestene våre burde kjøre i bakgrunnen hver gang vi endrer noe, og gi oss umiddelbar tilbakemelding når vi knekker funksjonalitet. På denne måten oppdager vi våre egne feil før resten av teamet blir påvirket av dem.

Det finnes flere verktøy som gjør dette for deg:

• Infinitest (Java)
• Autotest / ZenTest (Ruby)
• Nosyd (Python)

Det er imidlertid ikke vanskelig å lage et enkelt autotest-verktøy på egen hånd. Jeg synes at det er en god ide å bruke litt tid her og der på å forbedre sitt eget utviklingsmiljø. Vi har jo muligheten til å lage våre egne verktøy (smeden er en av få håndverkere som kan si det samme). Som utvikler bør man iallfall klare å slipe sine egne kniver, for å si det sånn. Og dette er en god anledning!

Et naivt script for autotesting implementerer du på en ettermiddag. Alt du trenger er et lite program som reagerer på endringer i prosjektfilene dine, og kjører testene etter behov.

Algoritmen er enkel: La scriptet kjøre regelmessig, f.eks hvert sekund. Kontroller “forrige endring”-klokkeslettet for alle filene i prosjektet. Dersom klokkeslettet på en eller flere filer har endret seg siden forrige kontroll, så kjør enhetstestene til prosjektet. Analyser output fra testkjøringen, og se hvorvidt noen tester feilet eller kode knakk helt (exceptions). Gi så klar tilbakemelding om testene er ok eller feilet.

Tilbakemeldingen kan være litt grafikk og lyd på desktopen (for eksempel med Growl eller Snarl), en lavalampe på pulten, blinkende LED-lamper på laptopen… vær kreativ! Bare sørg for er at du får en tydelig tilbakemelding på hvorvidt testene feiler eller ikke.

Filmklippet under viser hvordan mitt eget autotest-miljø fungerer. Koden er i dette tilfellet skrevet i et språk som heter Clojure og ser derfor kanskje litt pussig ut, men ikke heng deg opp i det: det som demonstreres er at jeg knekker og fikser tester, og får automatisk godt synlig feedback på dette underveis.

Ikke spesielt komplisert.

“Dette ser jo genialt ut! Hvorfor bruker ikke alle autotest-verktøy allerede?”

Vel, det finnes dessverre noen utfordringer.

Dersom autotesting skal fungere hensiktsmessig må testsuiten som kjøres kun bestå av raske enhetstester, ikke tunge integrasjonstester. Og enhetstestene må gå kjapt! En test-run må ta sekunder, ikke minutter, ellers mister du gevinsten ved den umiddelbare feedbacken.

Problemet med trege tester er betydelig. Det finnes workarounds: man kan analysere avhengigheter mellom tester og kode, kun kjøre de berørte testene, kjøre raske tester først, feilende tester først, nylig feilende tester først… Men mange av oss har dessverre erfart at det er vanskelig å få til et godt fungerende opplegg for dette i et vanlig moderat stort utviklingsprosjekt.

Så er ikke autotesting nyttig likevel, da? Jo! Autotesting fungerer knallbra i små prosjekter (som ikke har samlet på seg så mye kode ennå) og egenopplæring (når du lærer nye verktøy og språk og ønsker å ta små steg med kjapp feedback). Det kan kanskje også fungere i større prosjekter dersom du har muligheten til å segmentere koden og testene dine i mindre moduler på en hensiktsmessig måte.

I bunnen av denne artikkelen har jeg vedlagt et eksempel på hvordan et enkelt autotest-script kan se ut, implementert i Ruby. Scriptet er skrevet for OS X-miljø, men koden bør være relativt lesbar og enkel å porte til ditt eget favorittspråk og utviklingsmiljø.

Happy testing!

Eksempel:

# Command line command which launches all unit tests
RUN_TESTS_CMD = "mvn clean test"

# Pick up any changes in files matching this filepath
FILES_TO_MONITOR = "**/*.java"

# Determine test outcome by scraping test output for #telltale signs of failure or exceptions

def test_failed?(test_output)
  return (test_output["FAIL in"] != nil) # Any 'FAIL in' strings in test result indicates failure
end

def exception_occurred?(test_output)
  return (test_output["EXCEPTION in"] != nil)
end

# Indicate test state by turning the background color of the test terminal
# a different color - yellow red og green. Currently uses Mac AppleScripts, but could be
# an audible signal, lava lamp, or anything else instead.

def indicate_tests_running
  `osascript bin/autotest/make-term-yellow`
  puts "\n\n\n----------------------------------"
  puts "TESTRUN STARTED #{Time.now}"
  puts "----------------------------------\n\n\n"
end  

def indicate_test_success(description)
  `osascript bin/autotest/make-term-green`
  puts description
end  

def indicate_test_errors(description)
  `osascript bin/autotest/make-term-red`
  puts description
end  

$monitored_files = {} # Stores the last changed time of each file    

def files_changed? # Check if any files have been touched/saved since last check
  file_changed = false;  

  Dir[FILES_TO_MONITOR].each do |filepath|
    if(!File.new(filepath).ctime.eql?($monitored_files[filepath]))
      file_changed = true;
      $monitored_files[filepath] = File.new(filepath).ctime
    end
  end  

  return file_changed
end  

def run_test
  indicate_tests_running
  result = `#{RUN_TESTS_CMD}`  #Run the tests, pipe resulting console output back
  display_results(result)
end    

def display_results(testOutput)
  if test_failed?(testOutput)
    indicate_test_errors("SOME TEST(S) FAILED\n"+testOutput)
  elsif exception_occurred?(testOutput)
    indicate_test_errors("EXCEPTIONS OCCURRED\n"+testOutput)
  else
    indicate_test_success("ALL TESTS SUCCEED\n"+testOutput)
  end
end  

def test_loop
  while true
    if files_changed?
      run_test
    end
    sleep(1) #seconds between each poll for file changes
  end
end  

test_loop # Start testing!

Lean kommer fra en asiatisk kultur, der det kollektive og prosessen i seg selv er det sentrale. Lean er laget for å strømlinjeforme en spesiell måte å løse en kjent oppgave på. Agile på sin side kommer fra USA, der individet fremheves over alt annet (“Individuals and interactions over processes and tools”). Agile er først og fremst en effektiv måte å jobbe på når vi ikke kjenner veldig godt til omfanget og innholdet i oppgaven, og er nødt til å finne veien samtidig som vi går den.

I et foredrag på Scandinavian Agile Conference 2009 presenterte Jim Coplien disse 9 punktene der Lean og Agile er motstykker:

En gjennomgang av disse punktene kan være tema for et senere innlegg. Det jeg vil presentere denne gangen, er to praktiske øvelser som illustrerer noen av forskjellene og styrkene ved Lean og Agile. Øvelsene tar ca 5 minutter hver.

Øvelse 1: Agile

Finn en gruppe på ca 10-15 personer, og la de stå i et åpent område som de kan bevege seg rundt i. Hver person skal tenke på to andre personer i gruppa. Når alle har valgt ut sine to personer (uten å avsløre til noen hvem de har valgt), så er oppgaven som følger: Hver og en person skal nå plassere seg slik i rommet at han eller hun har nøyaktig like stor avstand til de to personene vedkommende tenkte på.

Før de får begynne å løse oppgaven, så er dette et morsomt spørsmål å stille til eventuelle prosjektledere i rommet: Hvis man skulle benytte klassisk prosjektledelse til å lede gruppa i denne øvelsen, hvordan skulle man gå frem da? Hvilke planer og retningslinjer kunne man lage som ville hjelpe dem fram til et raskt og godt resultat? De fleste vil snart komme fram til den konklusjonen at det er en ganske vanskelig (kompleks) oppgave.

Om vi benytter Scrum som eksempel på en smidig måte å løse dette på, hva ville en god Scrum master eller coach da si? Bare gjør det! Vi lar gruppa være selvorganiserende, og lar hvert enkelt individ ta ansvar for å på en selvstendig måte løse sin del av oppgaven, men i tett samarbeid med de andre i gruppa. Resultatet vil bli at etter en kort tid med tilsynelatende kaotiske og uorganiserte bevegelser, vil alle ha funnet likevektspunktene sine som til sammen løser oppgaven. Et resultat som ville være svært mye mer krevende å oppnå med en sentralt styrt prosess.

Øvelse 2: Lean

Hva så med Lean, hvordan kan det illustreres ved hjelp av en øvelse? Her trenger vi litt færre personer, ca 10 er fint. Gi en tilfeldig person i gruppa en gjenstand han kan holde i handa (ei tom flaske er et godt alternativ), og presenter dem for følgende utfordring: Gjenstanden skal nå sendes fra person til person i alfabetisk rekkefølge basert på fornavn. Det skal skje så raskt som mulig, og de vil bli tatt tiden på!

Ved første forsøk vil gruppa bruke litt tid på dette. De må fortelle navnene sine for å finne riktig rekkefølge. De vil typisk bruke et halvt til to minutter på å bestemme rekkefølgen og sende gjenstanden rundt. Fortell dem resultatet, og spør så om de kan gjøre det igjen, raskere. Det vil de naturlig nok klare, etter som de nå bedre kjenner navnene til hverandre.

Etter å ha fortalt dem tiden for forsøk nummer to, la dem forsøke en gang til, og be dem tenke på måten de står plassert på. De vil oppdage at det å stå på rekke eller i en sirkel, i alfabetisk rekkefølge, vil gjøre det enklest mulig å sende gjenstanden fra person til person. Vi eliminerer waste!

Hvor raskt er det mulig å klare det? Om de står i en tett sirkel, og hver enkelt så vidt berører gjenstanden før nestemann gjør det, kan de klare øvelsen på under et sekund. Det vil være en ganske dramatisk forbedring fra det første forsøket! Det viser hvor effektiv Lean kan være på denne typen oppgaver.

Oppsummering

Lean og Agile er laget for å løse forskjellige typer oppgaver. De kommer fra forskjellig bakgrunn, og selv om de virker like, så skiller de seg vidt fra hverandre på noen sentrale områder. Øvelsene over demonstrerer noen av de spesielle styrkene til de to prosessene. Disse styrkene er det viktig å huske på når man skal velge tilnærming til et prosjekt eller andre arbeidsoppgaver som krever en god prosess.

Hvilke erfaringer har du som leser gjort deg med Lean og Agile? Har du opplevd oppgaver eller prosjekter der de har passet spesielt godt eller spesielt dårlig?

Min erfaring er at det er ved produksjonssetting de virkelige utfordringene begynner, og da din prosjektgruppe trenger fokus. Nettopp da må styringsgruppen og involverte beslutnignstagere forstå at prosjektet trenger arbeidsro og gode rutiner, ikke nedleggelse, nye rapporteringsforpliktelser, bli gjenstand for budsjettkutt eller lignende. Utsagnet et system som ikke endres er et dødt system er virkelig sant i denne perioden. Husk det når du budsjetterer prosjektet og når du setter dine forventninger.

Det er alltid forbundet med risiko å ta en beslutning om konvertering og produksjonssetting, ofte resulterer det, i at man ikke klarer å skru av det gamle systemet likevel, eller at svært mange interessenter blir misfornøyde og skaper mye støy for prosjektet – den gamle løsningen fungerte jo bedre. Man kan teste så mye man orker før produksjonssetting, men Murphy’s lov slår til og ting går galt. Brukeren kan det ikke – da fungerer det ikke. Noe av det testteamet trodde var i orden viser seg kanskje også å skape en nedtur i begynnelsen. Opplevelsen trenger altså ikke bare være basert på reell mangel på funksjonalitet, men opplevd funksjonalitet. Fenomenet kan illustreres med en blodbadkurve, der man opplever at det nye systemet fungerer vesentlig dårligere enn det gamle systemet i en periode etter produksjonssetting.

Ved å gjøre de rette grepene kan imidlertid blodbad-perioden reduseres og gjøres minst mulig smertefull. Her er fire tips.

1. Styr forventningene i forkant – Blodbad-perioden er ofte den samme tidsperioden der styringsgruppen forventer at gevinstene skal realiseres, gjerne nokså umiddelbart. Dette er en umulighet hvis man ser på kurven over. Prosjektet er travelt opptatt med å prioritere feil, lære seg å drifte det nye systemet, lære brukerne å bruke det nye systemet og løse de mest kritiske tingene som mangler i systemet, ofte ved hjelp av tidkrevende workarounds inntil gode nok løsninger er på plass.

2. Gi prosjektet økonomisk handlingsrom – Det sikreste man kan gjøre for å sikre absolutt fiakso er å legge ned prosjektet i denne fasen. Likevel er ofte “pengene brukt opp”, man hadde jo ikke regnet med at man måtte jobbe når man hadde levert til produksjon og nedleggelse blir realiteten. Det å ikke ha penger til endringer og videreutvikling i denne perioden er den sikreste måten å redusere levetiden på det nye systemet dramatisk. Det kan også tenkes at de som har fått det nye systemet trenger litt tid på å lære det, så regn med noen vikarer.

3. Vær flink til å prioritere og operer med åpne prioriteringslister – Styringsgruppen ønsker rask realisering av visjonen og at prosjektet skal makte å følge den stiplede grønne utviklingsbanen. Svaret er ja, det skal dere få, men først må prosjektet få hodet over vannet i form av å løse de mest kritiske feilene. Deretter kan man prioritere forbedringer og nyutvikling. Et sikkert tegn på at man har med en umoden styringsgruppe å gjøre er dersom de i denne perioden forventer at prosjektet skal prioritere nye forretningskrav som plutselig har kommet opp når de ser det nye systemet. Prosjektgruppen bør prioritere utestående områder slik at det som er mest kritisk (eller lønnsomt) kommer først.

4. Avklar ansvar og organisasjonsmodell for vedlikehold tidlig – Etter produksjonssetting kan det være uklare ansvarsforhold knyttet til vedlikehold. Innse det med en gang – et system uten endring er et dødt system. Da må man vite hvordan endringene skal gjennomføres, testes og produksjonssettes også etter oppstart. Ofte “fryses” kanskje systemet for å unngå store endringer rett før oppstart, med den konsekvens at utviklerne som kunne løst feil raskt forsvinner over til andre oppgaver eller mister fokus. Realiteten er at det er i produksjonssettingsfasen at endringstakten, eller i hvert fall feilrettingstakten, bør være desidert størst. I hvert fall dersom man mener alvor med å snu blodbadet og realisere visjonen for prosjektet.

Legg merke til at jeg ikke foreslår å utsette produksjonssettingen. Dette er åpenbart eneste alternativ dersom man ser at selv de mest basale behov systemet er tenkt å løse ikke fungerer, men i så tilfelle har prosjektet et større problem og burde ha lært seg metoder som Scrum og EVO for lenge siden.

Legg også merke til at prosjektet endrer karakter den dagen man produksjonssetter. Det er ikke lenger et erstatningsprosjekt. Det er et smidig forbedringsprosjekt og må behandles som det!

Les mer på sterkbladning.no:

• Johannes om erstatningsprosjekter
• Ole-Vidar om driftsrammeverk (ITIL) vs utviklingsrammeverk (Scrum)

Markedsføring

Begynn med grunnleggende markedsundersøkelse. Hvem ønsker du å nå, og hva trenger de å lære om temaet ditt?

Skriv  en velformulert invitasjon til kurset. Lag en skikkelig pitch – selg temaet ditt godt! Bruk grunnleggende prinsipper fra markedsføring: fortell hvorfor leseren skal bry seg (benefits) før du røper konkret pensum og detaljer for kurset (features).

Annonser kurset ditt i mange kanaler: email, sosiale medier, ansikt til ansikt. Jo fler fora jo bedre.

Sørg for at det er lett å melde seg på. Tenk på dette som å gjøre prospekter til kunder – gjør terskelen for “kjøp” så lav som mulig.

Nå strømmer forhåpentligvis påmeldingene inn. Bruk litt tid på å ta kontakt med hver deltaker. Gjør dette så tidlig som mulig. Send påmeldingsbekreftelse og ytterligere praktisk informasjon, og undersøk samtidig erfaringsnivået og forventningene til den enkelte – dette lar deg skreddersy innholdet i kurset.

Planlegging og struktur

Etter stegene ovenfor bør du ha et visst inntrykk av hvem som kommer til å dukke opp på workshopen. Generaliser denne informasjonen i personaer – skal opplegget ditt passe for både Programmerer Pia og Mellomleder Magnus?

Tenk grundig gjennom overordnet struktur og pensum. Brainstorm omfang og innhold for kurset med fleksible teknikker som whiteboard, skisser og tankekart. Feiltrinn er enkle å fikse på dette stadiet; etter at du har begynt å implementere kurset blir de langt mer tidkrevende (akkurat som systemutvikling).

Hvordan skal du lære bort? Dersom du har nok tid så bør du vurdere en kombinasjon av metoder. Litt foredrag, litt “tegn og fortell”, og rikelig med praktiske oppgaver. Hver person har sin egen måte å lære på, forsøk derfor å formidle materialet på flere måter for å treffe alle. Det gjør ikke noe at materialet derfor blir gjentatt; repetisjon hjelper folk å lære.

Presenter både grunnleggende fakta og relatert kontekst. Med andre ord, fortell både “hva er det?” og “hvorfor skal jeg bry meg?”. Mikro og makro.

Publikum kan ha varierende grad av erfaring og kunnskap om temaet du lærer bort. Forsøk i så fall å gi noe til både nybegynnerne og de erfarne elevene.

Jeg liker å starte med litt forelesning med praktiske demonstrasjoner underveis. Dette gir folk et fundament. Så bør folk få praktiske øvelser å jobbe med. Fortell, demonstrer, la folk prøve selv. (Resten av artikkelen antar at du følger dette formatet).

Foredraget

Start sterkt. Presenter en klar agenda – “hva skal vi lære idag, og hvorfor?” Bruk minimal tid på å introdusere deg selv; deltakerne er interessert i hva du ønsker å lære dem, ikke hvem du er.

Unngå foiler med masse tekst. Korte tekster er bra, enkeltord bedre, et enkelt illustrerende bilde er best. Kanskje du til og med slipper unna med å bare fortelle, dersom du gjør det tydelig nok?

Korte foiler er bedre enn tettskrevne. Så. Korte. Poenger. Som. Mulig. Hver foil fungerer da også som en veldig presis huskelapp for deg som forteller.

Foilene dine trenger ikke være kunstverk, men tenk litt grunnleggende grafisk design:

• Finn en generell stil på forhånd slik at materiellet blir så konsistent som mulig. Presenterer du samme type informasjon (eksempler, kode, lister…) gjentatte ganger? Lag da en konsekvent mal for hvordan disse foil-typene skal se ut. Kode bør f.eks alltid ha samme font og størrelse.
• Bruk stor skrifttype. Velg farger som gir god kontrast mot hverandre. Hvordan kommer materialet ditt til å se ut når det projiseres på en hvit skjerm? I dagslys? Ti meter unna?
• Bruk repetisjon. Innhold som gjentas er lettere å huske.
• Bruk kontrast. Innhold som “hopper ut av siden” er minneverdig.
• Bruk bilder av høy kvalitet. Unngå kjedelig clip-art.
• Skriv kortfattet tekst med mye whitespace rundt – la innholdet ditt “puste”.
• Kutt ut standard-malene for powerpoint. Firmalogoer og andre grafiske snurredipperier er greit på introduksjonen og avslutningen av foredraget, men på resten av foilene medfører det bare visuelt støy.

Øvelsene

Ta høyde for å bruke mye tid på å lage bra praktiske øvelser. Dette er noen poenger å tenke på:

• Øvelsene bør være enkle i starten. La eleven føle seg flink!
• Lag et bredt utvalg av oppgaver, og gjøre det mulig å løse dem i fri rekkefølge. En lang kjede av påbyggende oppgaver kan føre til at en feil i en tidlig øvelse ødelegger for eleven senere – i verste fall setter eleven seg helt fast. La eleven hoppe til en hvilken som helst annen øvelse når som helst.
• Ta høyde for at folk har forskjellig erfaringsnivå og produktivitet. En måte å gjøre dette på er å legge til en “bonusoppgave” for de flinkeste i klassen på hver øvelse.
• Ikke krev at deltakerne skal forberede seg nevneverdig før kurset. Gjør det istedet enkelt å komme igang på selve workshopen. Tenk brukeropplevelse! For eksempel: dersom oppgavene krever programmering så bør du forsøke å gi et ferdig konfigurert utviklingsmiljø til eleven.
• Anta i utgangspunktet at internett og intranett ikke er tilgjengelig, så slipper du å få ubehagelige overraskelser. Forsøk istedet å gi elevene alt de trenger for å komme igang på selve workshopen.
• Sørg for at det er enkelt å distribuere ut handouts. Kjøp en haug usb-pinner, last inn filer på dem før kurset starter.

Siste forberedelser

Når grunnleggende struktur og innhold er på plass bør du trene på stoffet og polere det ytterligere. Øving, forbedring, øving, forbedring. Iterer på innholdet flere ganger. Dette er som vanlig skriveprosess; hver gang du kommer tilbake til stoffet ditt med friske øyne så ser du ting som kan forbedres.

Forsøk å bli ferdig med det meste av forberedelser noen dager før kurset. Da gir du deg selv langt bedre margin for å avsløre og utbedre uventede mangler i opplegget ditt. Den siste kvelden før kurset passer best til rolig refleksjon og eventuell siste finpuss.

D-dagen

Møt opp tidlig. Undersøk kursrommet. Sett opp din egen pc og juster lysnivået i rommet – du har ikke lyst til å jakte etter kabler, lysbrytere og gardiner underveis i kurset.

Hils på folk etterhvert som de dukker opp. Prøv å få til litt småprat. Du ønsker å skape kontakt med deltakerne så tidlig som mulig, så tjuvstart med dette før selve kurset starter. Det er langt mindre skummelt å prate til en forsamling dersom du har noen kjente og vennlige ansikter i forsamlingen allerede.

Så kommer den utfordrende biten (iallfall for meg!): selve foredraget. Forsøk å være  avslappet og tydelig. Kontroller kroppsspråket ditt. Hold et rolig og jevnt tempo. Gjør som sangere og kamsportutøvere: bruk magen aktivt. Hent stemmen din dypt i magen, ikke øverst i halsen.

Besvar korte spørsmål underveis. Henvis lengre diskusjoner til oppsummeringen på slutten. Spesielt smale temaer kan eventuelt tas på tomannshånd etter kurset.

Engasjer publikum. Still både retoriske og reelle spørsmål til rommet. La folk svare med håndsopprekning, individuelle svar eller gruppesamtaler. Oppfordre salen til å delta aktivt!

Del inn foredraget i korte sesjoner med hyppige pauser underveis, for eksempel en halvtime av gangen med fem minutter pause mellom. Gjør disse periodene enda kortere dersom rommet er smått og trangt; lav oksygentilførsel er ikke bra.

Vår oppmerksom på publikums reaksjon underveis, og tilpass tempo og innhold hvis nødvendig. Dersom tilskuerne kjeder seg bør du skynde deg til en mer spennende del av presentasjonen. Dersom de ser ut til å “falle av lasset” bør du senke tempoet og forklare tydeligere.

Gi folk handouts etter foredraget, ikke før. Du kjemper allerede om oppmerksomhet mot mange laptoper og mobiltelefoner i rommet, ikke undergrav deg selv ytterligere ved å gi ut lesestoff i tillegg. Fokus skal være på deg og hva du sier, ikke noen utskrifter du har delt ut.

Når de praktiske øvelsene starter bør du forsøke å aktivt sirkulere i rommet. Prat med deltakerne, sjekk hvordan det går med hver person/gruppe. Tilby hjelp hvis det er nødvendig. Vær tilstede som instruktør. Det er lett å stille spørsmål til deg hvis du er i nærheten og tydelig oppmerksom. En “fjern lærer bak et stort skrivebord” virker ikke like tilgjengelig.

Til slutt: be publikum om direkte tilbakemelding. Hva synes de kan bli bedre? Basert på dette, hold en enda bedre workshop neste gang!

Referanser

Presentation Zen inneholder enkle tips rundt foredragsholding og slides-mekking.

Creating Passionate Users er en fantastisk blogg om brukervennlighet og pedagogikk. Den oppdateres ikke lenger, men arkivene er en gullgruve.

TedTalks har masse eksempler på flinke foredragsholdere. Se og lær!

Bidragsytere

Takk til Siv Fjellkårstad, Johannes Brodwall og Markus Krüger, som alle var så vennlige å dele av sine egne kurs-erfaringer!

Dette er et levende dokument. Kom gjerne med egne erfaringer i kommentarfeltet under – jeg fletter inn gode forslag i artikkelen.

Dette tema var belyst på årets itSMF-konferanse som ble avholdt på Gardermoen 3-4 mars. ”Dei leikar ikkje saman – enno!” het presentasjonen til Bjørnar Tessem fra Universitetet i Bergen. Denne presentasjonen setter fokus på at det er samhandlingen mellom utvikling og drift som er mangelfull. Man er usikker på å la andre ”komme inn på sitt domene”, både fra utvikler- og driftsmiljøene. Hva skyldes denne usikkerheten? Er det frykt for å miste makt og innflytelse? Eller får man skylapper av sine egne ”good practice frameworks” enten de heter ITIL, CoBIT, Scrum, smidig eller noe annet? Dersom man får en for streng tolking av sitt eget rammeverk, så mister man den pragmatiske tilnærmingen.

Det er ingen tvil om at slike rammeverk bidrar til forbedring innen for sine respektive områder, men de kan også bidra til å stenge ute andre fornuftige innspill. Resultatet kan bli en religionskrig, der kundene og brukerne er de som må lide for den mangelfulle samhandlingen.

Utvikling og drift må i større grad ha følelsen av et felles ansvar for at tjenestene de utvikler og drifter vil tjene det formål de er tiltenkt på en måte som er effektivt for både brukerne og leverandørene.

Det smidige manifestet ble skapt av en gruppe svært talentfulle mennesker. Men alle sammen kom fra leverandørsiden av utviklingsprosjekter, noe som er tydelig allerede i den tredje av de fire verdiene:

Samarbeid med kunden framfor kontraktsforhandlinger

- som implisitt sier at “vi” ikke er kunden.

For å få ut de største gevinstene av smidige filosofier, må kundesiden også jobbe på en smidig måte. Dette betyr mer enn å skaffe en Produkteier som utviklerteamene kan jobbe med eller for. Kundesiden av prosjektet må jobbe ikke bare med utviklerne, men også med sin egen organisasjon og andre interessenter. Spesielt viktig er det at kundesiden av prosjektet må finne ut hvilke mål produktet må nå for å skape virkelig verdi for interessentene.

Så derfor lurer jeg på: Hvordan ville det smidige manifestet ha sett ut hvis det hadde blitt skapt av kunder i stedet for leverandører?

Her er resultatet av mitt lille tankeeksperiment.

Smidige verdier

Vi oppdager stadig bedre måter å utvikle systemer på, både ved å gjøre det selv og ved å hjelpe andre. Derved har vi lært oss å verdsette:

• Individer og samspill framfor prosesser og verktøy
• Fungerende system framfor utførlig dokumentasjon
• Å levere verdi til interessenter framfor å fullføre funksjonalitet
• Samarbeid med leverandør og egen organisasjon framfor kontraktsforhandlinger
• Å reagere på endringer framfor å følge en plan

Smidige prinsipper

(Merk: Nedenfor har jeg inkludert de original prinsippene, men uthevet de nye forslagene, slik at du enkelt kan se likhetene og forskjellene. Den norske oversettelsen av originalprinsippene er forøvrig basert på en diskusjon på smidig.no-forum.)

Vi følger disse prinsippene:

• (NY)
  Det hjelper ikke å gjøre tingene riktig hvis vi ikke gjør de riktige tingene. Vi må jobbe kontinuerlig med organisasjonen vår og med sluttbrukerne for å finne ut hva som er de riktige tingene.
• Vår høyeste prioritet er å tilfredsstille kunden gjennom å levere et verdifullt, kjørende system tidlig og hyppig.
  Vår høyeste prioritet er å skape verdi for interessentene gjennom tidlige og hyppige leveranser av programvare.
• Ønsk endringer i krav velkommen, også sent i utviklingen. Smidige prosesser utnytter endringer til å gi kunden konkurransefortrinn.
  Ønsk endringer i krav velkommen, også sent i prosjektet. Smidige prosesser utnytter endringer til å gi organisasjonen vår konkurransefortrinn.
• Lever fungerende programvare hyppig, fra et par uker til et par måneder, med preferanse for den korte enden av skalaen.
  Lever verdifulle løsninger hyppig, fra et par uker til et par måneder, med preferanse for den korte enden av skalaen.
• Forretningssiden og utviklere må jobbe sammen daglig gjennom hele prosjektet.
  Jobb sammen med interessentene og utviklerne kontinuerlig gjennom hele prosjektet.
• Bygg prosjektene rundt motiverte individer. Gi dem det miljøet og den støtten de trenger, og stol på at de får jobben gjort.
  Bygg prosjektene rundt motiverte individer. Gi dem det miljøet og den støtten de trenger, og stol på at de får jobben gjort.
• Den mest effektive metoden for å formidle informasjon til og innen et utviklingsteam, er å snakke ansikt-til-ansikt.
  Den mest effektive kommunikasjonsformen er å snakke ansikt til ansikt mens dere visualiserer samtaleemnet på papir eller tavle. Bruk andre former kun når tilleggsverdien er større enn tilleggskostnaden.
• Kjørende system er det primære målet på framdrift.
  Verdi realisert av interessentene er det primære målet på framdrift.
• Smidige prosesser fremmer bærekraftig utvikling. Sponsorene, utviklerne og brukerne bør kunne opprettholde et konstant tempo i ubegrenset tid.
  Smidige prosesser fremmer bærekraftig utvikling. Interessentene og utviklerne bør kunne opprettholde et konstant tempo i ubegrenset tid.
• Kontinuerlig fokus på teknisk kvalitet og godt design fremmer smidighet.
  Kontinuerlig fokus på høy teknisk kvalitet fremmer smidighet.
• Enkelhet – kunsten å maksimere mengden arbeid som ikke gjøres – er essensielt.
  Enkelhet – kunsten å maksimere mengden arbeid som ikke gjøres – er essensielt.
• De beste arkitekturene, kravene og designene vokser fram fra selv-organiserende team.
  De beste løsningene oppstår i selv-organiserende teams med klare mål.
• Med jevne mellomrom reflekterer teamet over hvordan det kan bli mer effektivt, og justerer arbeidsmåten sin tilsvarende.
  Med jevne mellomrom reflekterer alle involverte over hvordan de kan bli mer effektive, og justerer arbeidsmåten sin tilsvarende.

Oppsummerende ord

Jeg har holdt meg tett opp til de originale verdiene og prinsippene – kanskje for tett. Å ligge opptil originalen kan ha verdi – på en måte gir det kunde- og leverandørsiden en tydelig felles plattform. Dessverre det kan også bety at jeg overser noe viktig. Men det er ikke meningen her å skrive et helt nytt manifest (hvordan skulle jeg kunne det?), men heller leke rundt med “hva om…” og kanskje få fram noe verdifullt om likhetene og forskjellene mellom utvikleres og kunders perspektiv.

Hva synes du?

(takk til Johannes, Eli og Simen for innsikter og forslag som gjorde denne artikkelen bedre)

“If A System Is Working, Leave It Alone. Don’t Change Anything!”
- John Gall, Systemantics (1975)

Planen

Det gamle systemet hadde blitt uholdbart. Leverandøren ga ikke lenger support på maskinvare eller programvare, det var umulig å oppdrive kompetanse for å videreutvikle og det var ikke lenger vedlikeholdbart siden det var så kompleks.

Vi skulle derfor erstatte systemet med et nytt et. Bygget fra bunnen med moderne teknologi. Det burde bli enkelt, siden dagens system kan fungere som kravspesifikasjon. Vi hadde estimert arbeidet til 83 511 timeverk.

Vi ville naturligvis ikke investere store mengder arbeid i det gamle, døende systemet. Og dessuten var det umulig å integrere med. Så vi måtte bygge det nye systemet med all funksjonalitet, og så, en spennende helg om noen år, sette det i produksjon.

Slik høres introduksjonen til mange erstatningsprosjekter ut. I disse prosjektene har man et eksisterende system som typisk er kritisk for virksomheten. Av gode eller dårlige grunner har man valgt å gjennomføre et prosjekt som skal erstatte hele den gamle systemet med et nytt system som oppfyller samme målsetning.

Denne planen burde med en gang ringe noen varselbjeller. Hva er egentlig poenget med dette prosjektet? Prosjektet ønsker å videreføre dagens tjeneste med et nytt og moderne system. Og det er billigere måter å gjøre det på.

Uortodoks observasjon #1:

Et erstatningsprosjekt er en dyr måte å forlenge livet til vår nåværende forretningsmodell.

Det virker umulig å komme seg forbi hindrene i form av support, kompetanse og vedlikeholdbarhet. Men dersom vi doblet lønna til alle som ville programmere COBOL, så ville vi nok få nok kompetanse. Det er mulig å videreføre systemet. Det er bare veldig dyrt. Men det er også fantastisk dyrt å erstatte et system fra bunnen. Man kan bruke mange dyre teknikker for å holde systemet i gang før der lønner seg å erstatte.

På de fleste systemer er imidlertid support, kompetanse og vedlikeholdbarhet ikke de eneste, og kanskje ikke de egentlige motivene. Det finnes andre motiver, både dårlige (noen vil ha et stort prosjekt på CV eller jobbe med ny teknologi) og gode (vi ser muligheten til å levere verdi).

Først når erstatningsprosjektet tilfører forretningsverdi er det verdt å gjennomføre. Erstatningsprosjekter for å redusere kostnader eller forlenge levetiden på en utdatert forretningsmodell er en dårlig ide.

Virkeligheten

“A Complex System Designed From Scratch Never Works And Cannot Be Made To Work. You Have To Start Over, Beginning With A Working Simple System”
- John Gall, Systemantics

Den forrige arkitekten hadde holdt på med systemet i tre år. Og organisasjonen hadde ingenting å vise til. Det var ikke blitt ferdig, og han hadde insistert på at det var umulig å levere deler av systemet.

Styret er lei av denne unnskyldningen, og om administrerende direktør ikke finner en arkitekt som kan bevise at investeringene har verdi, er det han som må gå.

Et forsinket prosjekt mister politisk goodwill. Det er bare en måte for et prosjekt som har mistet troverdighet å redde seg på: Man må levere noe. Og da må man spise noen kameler.

Uortodoks observasjon #2:

Det nye og det gamle systemet kommer til å leve sammen.

Heldigvis er dette gode nyheter. Med en gang vi vet at det nye og det gamle systemet må leve sammen, åpner det døren for en rekke muligheter til å tenke bedre.

Gradvis erstatning

Først, her er fire patterns for å gradvis erstatte et system:

• Delt database: Dersom det gamle systemer benytter en relasjonsdatabase kan det nye systemet bruke denne direkte. Det gjør det mulig å levere deler av det nye systemet nesten umiddelbart, men det legger føringer for designer av det nye systemet som man kanskje kunne unngått.
• Import/eksport: Før eller siden må vi forholde oss til de dataene som finnes i det gamle systemet. Ta kostnaden tidlig og eksporter data til det nye systemet. Men vær forsiktig: Det er vanskelig å ha to mastere for data. Start med å la det gamle systemet være master.
• Datatjenestelag: Dersom du ønsker å erstatte det gamle systemets datalager, kan du innkapsle dette i en tjeneste. Legg imidlertid merke til at datatjenester har høyt endringsbehov og tjenester som deles i et stort prosjekt er kostbare å endre.
• Parallell produksjon: Dersom det nye systemet utvikler funksjonalitet som finnes i det gamle, se om det er mulig at begge versjonene kan være i produksjon samtidig. Da reduseres konsekvensen dersom den nye versjonen inneholder feil, siden å rulle tilbake en produksjonsetting er enklere. Dette gjør at det kan være mulig å produksjonsette med mindre testing. Det nye systemet kan også starte med et subset av brukerne. Dermed kan man utsette noe av ytelsesoptimaliseringen til man har bedre erfaring fra faktisk bruk.

Men det krever mer enn teknikker for å sette sammen systemene for å lykkes. Man må makte å finne oppgaver som man kan jobbe på og realisere verdi for organisasjonen i løpet av erstatningsprosjektet. Her er fire patterns for å finne områder å erstatte:

• Risiko: Enkelte endringer er så viktige at uten dem, vil prosjektet regnes som mislykkes. For prosjekter relatert til pensjonsreformen vil det være katastrofalt om man ikke kan implementere det nye regelverket. Andre systemer har lenge hatt kjente svakheter som man har forpliktet seg til å utbedre. Fiks dette først!
• Kostnad: Organisasjoner som benytter systemer har ofte noe arbeidsoppgaver som er ekstra arbeidskrevende. Kanskje det er å punsje data, eller å overføre data fra et system til et annet. Eller kanskje det er kundene som ringer og spør om hvordan saken deres ligger an. Ved å velge et slikt område kan prosjektet levere gevinst tidlig.
• Isolerte brukere: Mange systemer har brukergrupper som bare benytter en liten del av systemet. Det kan være lurt å starte med en slik brukergruppe, ettersom man kan erstatte hele den delen av systemet de benytter på noen få leveranser.
• Nye brukere: Mange organisasjoner ønsker å lage selvbetjeningsløsninger for publikum. Disse er også gode og vanlige steder å starte et fornyingsprogram.

Arkitektur

“…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”- Conway’s Law

En arkitekt på et stort prosjekt som lar prosjektlederen bestemme hvilke arbeidspakker hvert team skal jobbe med har begrenset mulighet til å påvirke prosjektets suksess.

Som arkitekt er det ofte fristende å jobbe med en målarkitektur. Men for et stort prosjekt blir målarkitekturens største føringer organisasjonen som skal utvikle systemet. Å oppfylle prosjektets behov for at folk kan jobbe uten å konstant ramle i beina på hverandre må prioriteres over andre arkitekturmål.

Jo flere kokker, desto mer søl. Det er din jobb å sørge for at ikke alle må være på samme kjøkken. Eller enda verre: Løpe mellom alle kjøkkenene.

Uortodoks observasjon #3:

I store prosjekter er organiseringen den viktigste faktoren i arkitekturvalg.

Min erfaring er at det finnes noe fundamentale grenser for hvor mange personer som kan samarbeide:

• 4-6 personer kan jobbe med en person som dekker arkitektur, analytiker og teamleder-rollene. Dersom gruppen blir større enn dette, må man typisk ha tre personer for å dekke disse rollene.
• 10-12 personer kan jobbe på den samme koden og med den samme produktkøen uten å komme i beina på hverandre. I alle fall så lenge de kommuniserer daglig
• 30-35 personer kan jobbe med en kodebase som er kontinuerlig integrert. Dersom det er flere, vil tiden man bruker på å rette integrasjonsfeil bli en betydelig kostnad.

Og når prosjektet blir for stort for kontinuerlig integrasjon, må gjenbrukt kode versjonshåndteres. Dette betyr at det vil være dyrt å gjøre endringer. Kode som ikke kan endres blir ofte dårlig kode. Så gjenbruk ut over 30-35 personer er overraskende dyrt.

Til slutt bør team ha som målsetning å produksjonsette hver tredje måned. Dette er veldig vanskelig å gjøre dersom en leveranse inneholder mange deler som ikke er kontinuerlig integrert. Deler som ikke er kontinuerlig integrert bør fortrinnsvis produksjonssettes helt separat fra hverandre.

Konklusjon

Et prosjekt som skal erstatte dagens system uten å endre forretningsprosessene har feil fokus. Modernisering er bra, men ha fokus på verdien til andre enn de som vedlikeholder systemet.

Vi har en rekke antagelser om hvordan erstatningsprosjekter vil fungere. Etter min erfaring er mange av disse antagelsene feil. Du kan godt ha annen erfaring, men her er min:

• Et erstatningsprosjekt er en dyr måte å forlenge livet til en eksisterende forretningsmodell
• Det nye og det gamle systemet vil leve sammen
• I store prosjekter er organiseringen den viktigste faktoren i arkitekturvalg

Vi får til erstatningsprosjekter ved å levere gradvis.

“Galls Law: A Complex System That Works Is Invariably Found To Have Evolved From A Simple System That Worked.”
- John Gall, Systemantics, 1975

Lunch #60, Copyright: Børge Lund. Bilde brukt med tillatelse fra opphavspart (klikk for større versjon).

Vi lo godt da vi leste denne stripa. Den setter fingeren på både sannheter, usannheter og fordommer.

Alle som har jobbet i systemutviklingsprosjekter vil nok kjenne seg igjen her. Vår påstand er at de som kjenner seg mest igjen er de som ikke har jobbet med brukersentrerte designere eller smidige utviklere.

I stripa er kulturforskjellene tydelige ved første øyekast. Det er ikke alle som ser verdien av å gå pent kledd på jobb, for eksempel. Den stereotype utvikleren går i en nerdete t-skjorte fra ThinkGeek, mens designeren går med moteriktige briller og skulderveske. Designere er kun opptatt av overflaten og skal ha vetorett på alt som angår brukergrensesnittet (designeren vet selvfølgelig best). Utviklerne hater selvfølgelig designerne fordi de vet best selv. Og utviklerne bryr seg ikke om slike uviktige detaljer som brukergrensesnitt. Ikke har de stilsans heller. Men de viktige problemene kommer med tankesettet. De andre er alt for opptatt med noe som de tror er et viktig fundament for systemet, men som egentlig ikke har noe å gjøre med det som skal lages.

Slik er det lett å bli selvhøytidelig og ikke se verdien av hverandre. Er det noe både utvikleren og designeren faktisk har til felles er det en tendens til å kunne oppleves som primadonnaer av andre på prosjektet. Vår erfaring er at de begge ønsker å lage et godt system – de bare angriper dette på forskjellige måter og fokuserer på forskjellige ting.

Stereotypen av det konfliktfylte forholdet mellom designere og utviklere er noe vi har opplevd på kroppen. Det er slitsomt og lite konstruktivt. Men vi har også opplevd konstruktivt arbeid der vi lærer av hverandre. Vår erfaring er at vi sammen blir sterkere.

“Moderne” brukersentrerte designere og “smidige” utviklere har fokus på hva som gir verdi for brukeren av systemet; begge er opptatt av feedback som gir innsikt; begge er opptatt av kvalitet. Og de har gjerne forskjellig fokus som gir grunnlag for læring og kreativitet.

En designers styrke er å se det som skal leveres i den sammenhengen det skal brukes. En utvikler er opptatt av hvordan man kan bygge systemet. En designer som ikke skjønner utviklerens perspektiv har ingen måte å få gjort sine ideer virkelige på. En utvikler som ikke skjønner designerens perspektiv har ingen måte å vite hva han egentlig skal lage.

Brukersentrerte designere ønsker å lage de beste løsningene som er mulig, med de ressursene som er tilgjengelig. Gode designere jobber hardt for å forstå hvem brukerne er og hva behovene deres faktisk er. De må ha en visjon for systemets brukeropplevelse. Selv om designeren er den som formidler denne visjonen, er det ikke designerens visjon alene. Den er utviklet i samarbeid med utviklere, prosjektledere, brukere og andre interessenter.

Den moderne trenden blant utviklere er smidige metoder som Scrum, Lean og Extreme Programming. Felles for smidige metoder er at de er opptatt av konkrete resultater av arbeidet. Da er det essensielt å ha forståelse for hvem som mottar disse resultatene.

Fellesnevneren for disse metodene er at de innser at man må forstå hele problemet for å kunne lage en god løsning. Problemforståelsen starter alltid med å forstå hvem som får verdi av systemet og hva denne verdien består i. En naiv innfallsvinkel kan stoppe ved kunden (produkteier) som betaler for prosjektet. I stedet foreslår vi å observere brukerne av systemet.

For å få bygget opp forståelsen har brukersentrert design en verktøykasse der et av de viktigste verktøyene er brukerintervjuer. Under et brukerintervju setter vi oss ned og snakker med de som faktisk skal bruke systemet. Poenget er å bygge opp forståelsen for de underliggende verdiene systemet kan løse, ikke bare de observerte symptomene. For eksempel kan vi bruke noen dager til å lytte på henvendelsene fra publikum til saksbehandlerne som skal bruke systemet. Da kan vi identifisere de vanligste problemområdene.

Smidige metoder benytter brukerhistorier til å definere arbeidsoppgaver. Essensielt for brukerhistorier er at man beskriver hvem som er interessert i funksjonen som skal lages og hvilken verdi den gir. For eksempel “for å kunne forklare hva jeg får i pensjon, som en pensjonist ønsker jeg at saksbehandleren får en grafisk sammenstilling av alle mine pensjonsytelser.” Dette er en av flere maler som brukes til å skrive brukerhistorier, og den er på formen “for å oppnå en forretningsverdi, som interessent ønsker jeg at bruker får en funksjon“.

Brukerorientert design gir verktøyene for å skaffe innsikt i brukernes behov. Smidige metoder gir verktøyene for å levere et system som oppfyller disse behovene. Design uten utvikling er lammet, utvikling uten design er blind.

Sammen blir vi sterkere. La fordommene falle!

To teknikker vi mener du bør prøve:

• Brukerhistorier
• Brukerintervjuer

Denne artikkelen er resultatet av samarbeid mellom Ram (designer) og Johannes (utvikler).

Fokus på “hvorfor”, ikke “hvordan”

Hva forsøker denne testen å uttrykke:

Når en bruker registrerer en betaling med beløp “-1234567890″, så skal brukeren se en feilmelding

Hva med denne:

Når en bruker registrerer en betaling med et negativt beløp så skal brukeren få en passende feilmelding

Magiske tall, tekster og verdier i tester skjuler hva vi forsøker å spesifisere. Noen flere eksempler: “når en bruker utelater et eller flere påkrevde felter, så skal brukeren få en feilmelding knyttet til de manglende feltene”, “gitt at brukeren leverer en lottorekke med for få tall”.

Å koble slike tester mot systemet krever mer arbeid, spesielt de første gangene, men testene blir mye klarere etterpå. Og hovedformålet med en akseptansetest er at den er en spesifikasjon som kan diskuteres mellom prosjektet og omverdenen. Og da er det viktig å være klar. Noen ganger vil det virke svært vanskelig å automatisere forståelige spesifikasjoner. Da bør du huske at en god beskrivelse er mer verdifull enn en dårlig test.

Given-when-then

Noe av det første du lærer med tester er “bruk formen ‘gitt X, når Y, så Z’”. Men det er ikke alltid så klart hva X, Y og Z skal være. Tester består av tre typer steg:

• Arrange (oppsett, “given”): Beskriver tilstanden til systemet før testen starter. Typiske eksempler er “gitt at det eksisterer en bruker med utestående betalinger“, “gitt at tjenesten levert fra vår partner har registrert et varenummer” eller kanskje “gitt at det er en fredag” (du får vente til freddan). Avhengig av systemet og tilstanden vi beskriver, kan testen benytte disse stegene på forskjellige måter: Vi kan sette opp brukeren og betalingene i systemet, vi kan se på steget som en forutsetning som vi sjekker om er oppfylt, for eksempel ved å gjøre et søk mot tjenesten fra vår partner, vi kan forutsette, eller endog håpe at det er oppfylt og vi kan la steget kun være dokumentasjon, slik at når testen feiler, så vet vi noen ting vi kan verifisere manuelt, eller det kan være en ren løgn. Kanskje systemet er satt opp på en spesiell måte slik at det ikke er avhengig av ukedagen. Men vi har lyst til å dokumentere hvordan det hadde sett ut om det hadde vært “på ordentlig.”
• Act (utfør, “when”): Beskriver stimuli inn fra omverden. “Når brukeren registrerer en ny betaling,” “når klientsystemet sender en betalingsforespørsel med manglende kundeinformasjon”. Disse kan implementeres på flere måter i de fleste systemer: Et test av et web-grensesnitt kan simulere en klient med for eksempel webdriver, den kan gjøre et http-kall og direkte, eller testen kan bruke klassene som implementerer tjenesten direkte. For funksjonelle tester foretrekker jeg nesten alltid det siste. Det gjør at testene vil kjøre hundre ganger raskere, og vil som regel innebære mindre jobb. Husk: Det er ikke nødvendig å teste brukergrensesnittet på nytt for hver valideringsregel eller spesialtilfelle i applikasjonen din.
• Assert (sjekk, “then”): Beskriver hvordan systemet skal reagere på stimuli og hva tilstanden til systemet skal være etterpå. For eksempel “så skal brukeren få en feilmelding om at alle betalinger må være utført før en ny betaling kan registreres”, “så skal den nye betalingen ikke lagres i systemet.”

Veien fra testscript til spesifikasjoner

Når prosjekter først tar i bruk FitNesse er det veldig vanlig å se tester som ser cirka slik ut:

• Putt inn en kjempeliste med rader med en bråte kolonner inn i tabell A.
• Putt inn en ny kjempelist med rader etc i tabell B
• Send inn et kjempemessig XML dokument
• Sjekk at svaret matcher et nytt XML dokument

Dette er ikke en spesifikasjon – det er et testscript. Og det er ikke slike tester som gir verdi til et prosjekt. Men det er et sted å starte, for det krever ikke så veldig mye kreativitet. Og vi kan gjenbruke lærdommen fra slike tester. Men før det blir en hel skog av tester som dytter XML-dokumenter hit og dit, kan det være lurt å løfte testene opp på et mer logisk nivå:

• Gitt at det ikke eksisterer noen betalingsforespørsler
• Og en bruker er registrert
• Når brukeren sender inn en betalingsforespørsel med ett gitt problem
• Så skal brukeren få feilmeldingen en gitt feilmelding

I FitNesse-terminologi kan en slik test implementeres som en ColumnFixture. Det vil si: Hvert par av “problem” og “feilmelding” er en rad i en tabell. Slik kan vi uttrykke mange regler ved systemet klart og konsist.

Dersom du har startet å gå veien med testscript, er det ikke vanskelig å snu: For hver rad i den nye spesifikasjonen din skal du utføre alt det testscriptet ditt gjorde.

Jeg vil bruke jobben med akseptansetester til ikke bare å gjøre automatiske kjøringer av systemet mitt, men til å spesifisere og diskutere de egentlige kravene brukerne mine bryr seg om. Og dersom jeg må velge mellom tester som lar seg automatisere og spesifikasjoner som beskriver kravet, vil jeg alltid velge det siste.

Ken argumenterer for at det er Jeff Sutherland og ham selv som har definisjonsretten på hva Scrum er. Folk som bruker versjonen som lå hos Scrum Alliance, jobber derfor ut fra materiale som ikke er riktig, i følge Ken. Jeg tror ikke at Ken og Jeff med rette kan hevde at det er dem som har definisjonsretten og alle andre må bare godta det. Scrum er sjenket til verden, og verden hører på de stemmene de vil høre på.

Samtidig ser jeg behov for å definere hva som er Scrum, slik at ikke alt mulig rart kan kalles “Scrum” (men akkurat dét ser ut til å være en håpløs kamp…) Scrum Alliance ser ut til å ville høre på Ken og Jeff, for de har fjernet sin gamle versjon. Et positivt poeng å ta med seg er uansett at Ken mener Scrum ikke er statisk, men må utvikle seg.

Den oppdaterte Scrum Guiden på www.scrum.org inneholder noen overraskelser. Den største, for meg, er at Ken og Jeff har fjernet alt snakk om “visjon”. Tidligere var visjonen omtalt som grunnlaget for Produktkøen, men nå er det ikke mer visjon igjen. Jeg er kritisk til om dette er et steg i riktig retning. Det største videreutviklingspotensialet for smidig systemutvikling ligger i å gi mer støtte og verktøy til Produkteier i å finne og definere verdi – typisk visjon og annet arbeid som skjer i forkant av utviklingen. Jeff og Ken går motsatt vei og viser med det at de ønsker at Scrum skal fortsette å være en utviklersentrert metodikk. Synd for både dem og Scrum.

Jeg liker godt innledningen, hvor Jeff og Ken sier at Scrum har tre bein. I tillegg til (faktisk foran) de velkjente inspeksjon og tilpasning kommer nå synlighet (“transparency”).

Seremonier har endret navn til tidsbokser og det er nå seks av dem: Release Planning Meeting, Sprint Planning Meeting, Sprint, Daily Scrum,  Sprint Review og Sprint Retrospective. Jeg liker godt at Release Planning Meeting har kommet inn. Noen savner kanskje demoen? Den ligger inne i Sprint Review, men det er lagt vekk på at demoen bare er en del av Sprint Review – mesteparten av møtet går til diskusjon om det som er laget og veien videre.

Scrum Guiden er obligatorisk lesning for alle som er opptatt av smidig systemutvikling. Og så kan vi debattere videre hva som er “riktig” Scrum…

Denne postingen er oppdatert etter at flere personer med rette hevdet at jeg ikke hadde et helt klart bilde av hva den gamle scrum guiden inneholdt (takk!). Inni dette er det sikkert en lekse angående det å stole for mye på hukommelsen.

De aller fleste artikler, temanummer osv. om smidige metodikker har så langt framstilt smidige metodikker på en svært rosenrød måte. Smidig systemutvikling er uten tvil et stort skritt framover i forhold til tradisjonell systemutviklingsmetodikk. Imidlertid er smidig utvikling i sin nåværende form ikke endestasjonen. Vi kan – og må – bli enda bedre.

Det finnes reelle utfordringer ved bruk av smidige metodikker, og det må vi også tørre å diskutere. Dét er viktig for at smidig utvikling skal bli en suksess, leve opp til sitt potensiale og ikke bare bli nok en hype på historiens gravplass. Her vil jeg nevne tre av de utfordringene jeg er opptatt av om dagen.

Levere verdi

Den første utfordringen gjelder å levere verdi. Smidige metodikk har som prinsipp å levere verdi tidlig og hyppig, og det mest verdifulle først. Dette gir bedre cashflow og ROI, og er et flott prinsipp.

I praksis leverer imidlertid smidige prosjekter funksjonalitet, ikke verdi. Stort sett aner vi ikke hvor mye verdi funksjonaliteten har for organisasjonen, eller om det kanskje ville vært mer lønnsomt å ikke utvikle en gitt funksjonalitet. Vi bare overlater til Produkteieren (kunden) å prioritere funksjonaliteten, og så håper vi at det fører til at vi leverer høyest verdi først og at ROI blir så høy som mulig. Kanskje det stemmer, kanskje ikke – det vet vi ikke, vi bare tror.

Vi trenger altså bedre måter å måle verdi på.

Styre mot mål

Den andre utfordringen er at smidige prosjekter fortsatt i for stor grad styrer mot kundens krav, ikke mot kundens mål. Den etter hvert velkjente Produktkøen (Product Backlog) fra Scrum er et eksempel på dette. Vi beskriver krav som brukerhistorier, legger dem inn i Produktkøen, og deretter følger vi framdrift i forhold til ferdigstillelse av kravene. Vi er åpne for å endre på kravene og omprioritere, mye mer enn på tradisjonelle prosjekter, og det bidrar absolutt til bedre resultater for prosjektet.

Imidlertid er det måloppnåelse som er viktig, ikke kravoppnåelse. Kravene er bare et sett med hypoteser for hvordan man kan nå målene. Vi trenger altså mer fokus på å definere mål og styre mot måloppnåelse. Det bør nevnes at EVO, utviklet av Norges egen Tom Gilb, er et velprøvd alternativ med fokus på måloppnåelse.

Mer støtte til Produkteieren

Den tredje utfordringen er at mye av det som er mest krevende, særlig i Scrum-prosjekter blir dyttet over på Produkteieren, dvs kunden. Og dette er samtidig ting som i stor grad avgjør om et prosjekt blir en suksess eller ikke, så som god forankring i organisasjonen, god balanse mellom ulike interessehavere, riktig prioritering av hva som blir med og hva som ikke blir med, osv. Allikevel sier vi ikke så mye om hvordan Produkteieren skal klare disse tingene. Produkteieren er ofte meget kompetent på sitt fagområde – men det fagområdet er vanligvis ikke prosjektstyring.

Så mens utviklingsteamet jobber lykkelig i vei, beskyttet fra forstyrrelser fra omverdenen, må Produkteieren prioritere ønsker, forankre beslutninger, forhandle enighet, drive internpolitikk – samtidig som hun skal bistå utviklingsteamet med alle ønskelige avklaringer.

Vi har gjort store framskritt på arbeidsmåten til utviklingsteamet, der jobber vi på en mye mer solid måte enn før. Nå må vi løfte blikket fra design-, utviklings- og testjobben. Vi må fokusere mer på Produkteieren og organisasjonen rundt, og gi reell støtte til Produkteierens viktige rolle.

Ta erfaring på alvor

Vi trenger altså bedre måter å måle verdi på, mer fokus på mål og måloppnåelse, og bedre støtte til Produkteieren og organisasjonen rundt. Men dette er kun tre utfordringer som jeg synes er viktige, andre vil være mer opptatt av andre utfordringer – ut fra deres situasjon og erfaring. Hovedpoenget er at vi nå begynner å diskutere disse reelle utfordringene som folk møter i praksis.

Så langt har dyktige folks konkrete utfordringer ofte blitt besvart med varianter over temaet “Men dere gjør det ikke riktig”. Slike svar hjelper ikke. Og skal smidig systemutvikling bli en suksess, må det være hjelp å få også når man sliter. Og like viktig: Hvis vi avfeier de utfordringene folk opplever, hindrer vi oss selv i å utvikle og forbedre den smidige metodikken, fordi vi ikke tar tilbakemeldingene fra praktisk bruk på alvor.

Som en av entusiastene som har jobbet for å spre smidig utvikling i en årrekke, gleder jeg meg over at smidig systemutvikling etter hvert har blitt godkjent og omfavnet i Norge. Markedsføringen har virket, nå må vi slutte å evangelisere og heller ta fatt på utfordringene.

Smidig systemutvikling i sin nåværende form er et stort steg videre, men ikke endestasjonen. Vi må fortsette å forbedre oss, basert på tilbakemeldinger.

Dét er den smidige kjernen i all sin enkelhet.

Dette innlegget er hovedsaklig basert på en artikkel jeg hadde i Computerworld i april 2009.

For noen uker siden hadde jeg en interessant erfaring på prosjektet mitt. Jeg og produkteieren fra kunden satt oss ned og så hva vi hadde produsert de siste to ukene – fire “brukerhistorier” som beskrev hva applikasjonen skal gjøre. Hver hadde en estimert relativ kostnad. Meg: “Ett poeng, tre poeng, to poeng, ett poeng, det blir syv poeng totalt.” Kunden: “Ok. Og denne iterasjonen kostet 140.000 kroner. Det blir 20.000 per poeng, ikke sant.” Jeg: “Høres riktig ut. Så denne oppgaven (peker på en brukerhistorie) kostet seksti tusen. Oi, det var dyrt.” Kunden: “Oi. Ja, det var dyrt.” Stillhet. Litt ukomfortabel latter.

Dersom du blir helt ferdig med ting under veis i prosjektet og du holder greie på hva du gjør, blir plutselig prisen på arbeidet veldig tydelig. Både for kunde og leverandør kan dette være et skummelt øyeblikk, for utviklingsprosjekter er alltid dyrere i praksis enn det føles ut som de burde være i teorien.

En ærlig leverandør vil ikke love å levere billigere enn man har vist å levere så langt. En ærlig kunde vil vite at det blir dyrt uansett leverandør og at informasjonen om kostnaden har en verdi i seg selv.

Men både den som skal svare til sin kunde og den som skal svare til sin styringsgruppe kan få hjertet litt i halsen første gang man faktisk får erfaringstall på hva prosjektet koster. Man føler seg litt naken. Men det er befriende også. For da kan man ha en dialog som er basert på fakta i og ikke bare følelser.