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.

Det finnes en rekke innovasjonskonsulenter som gjerne hjelper til med den kreative fasen, eller the Fuzzy Front End (FFE). En kreativ seanse på 2 timer, 80 ideer på gule lapper, ett hav av muligheter – hva skjer så? Ofte veldig lite. Enten er ideene som kommer inn for lite markedsrettet (nye kleshengere i garderoben…), eller man klarer ikke å realisere potensialet i de ideene som faktisk er gode fordi prosjektet ikke blir dratt fremover eller ideene ikke blir valgt ut blant de 80 andre. Man ender opp med at alle ideene blir “liggende i skrivebordsskuffen”, kanskje sporadisk lest men ofte glemt. Isteden burde man valgt de fem beste og dratt de videre med sin beste prosjektleder. En studie omtalt og gjennomført på nytt på stammen.no viser sågar at det ikke er de kreative workshopene ideene kommer fra, men fra naturen!

Nå finnes det altså en rekke sosiale, gjerne nettbaserte verktøy for å gjøre samhandlingen bedre og mer rettet mot innovasjon. Mange av dere kjenner sikkert til åpne sider som myStarbucksIdea der alle kunder av Starbucks oppfordres til å komme med ideer. Mange firmaer, har kjørt flere interne konkurranser med lignende sider for å få frem ideer. Vi i Steria brukte i sommer Spigit som samhandlingsverktøy for å få inn ideer først, og deretter drive prosessene videre nettopp for å unngå at ideene blir liggende i en skuff, men sørge for at de blir kommentert, utredet, videreutviklet, besluttet gjennomført, forankret, testet ut på kunder og realisert.

Innovation management software er et område som har modnet kraftig de siste to-tre årene. Det finnes lister over løsninger her, her og her og finn.no har hatt sin finnOpp-løsning siden juni 2007.

Porteføljen av løsninger kalles gjerne innovation management eller idea management tools. Har din bedrift tatt i bruk slike løsninger?

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!

Fredag 28. mai var temaet for kvelden miljø og bærekraftig fremtid. Vi viste følgende foredrag:

• Anders Lindgren: Sustainability
• Bill Gates: Innovating to Zero
  Bill Gates snakker om løsninger på klima- og energikrisen og hvor langt de er unna.
• Shai Agassi: En dristig plan for elektriske biler
  Agassi har allerede konvertert et helt land til å kjøre uten olje. Her presenterer han en ny modell for elektriske biler som også ser på infrastrukturen rundt bilene.
• Dan Barber: How I fell in love with a fish
  En kjærlighetshistorie som belyser hvordan matvareproduksjon foregår i dag, og som viser at det er mulig å produsere bærekraftig dersom vi tenker annerledes.
• Stewart Brand: Slumbyer er en bra ting
  På 3 minutter viser Brand oss hvorfor slumbyer er bra, både for de som bor der og for befolkningstallet på kloden.

Bonusforedrag: Bill Gates nevner i sitt foredrag “geoengineering” — Hvordan vi kan endre været på kloden for å bremse effekten av oppvarmingen.
David Keith: En overraskende ide for å løse klimaendringer

Hva synes du om disse foredragene? Har du tips til andre gode foredrag vi bør vise? Si ifra i kommentarfeltet!

Dette er definitivt en navnestandard som mange synes å mene noe om. La oss derfor krympe dette inn til å omhandle navnestandard for servere.  Satt på spissen finnes det i hovedsak to strategier. Dette er den enkle og kompliserte strategien.

Den enkle strategien går ut på å navngi serverne sine med et løpenummer for eksempel server001, server002 osv. En annen variant i kategorien enkel, kan være å velge ut et tema fra noe man har kjært. Eksempelvis karakterer i Andeby, for deretter å kalle serverne sine for Donald, Pluto og lignende. Denne varianten bør velges med varsomhet i miljø som eksponerer tjenestenavn direkte mot forretning og kunder som ikke nødvendigvis er like begeistret for temaet.

Strategien som undertegnede definerer som komplisert, baserer seg på en modell som søker å gi tilleggsinformasjon ut i fra serverens navn. Dette kan fungere godt. Et eksempel kan være navnet oslapp001 som indikerer at dette er applikasjonsserver 001 plassert i Oslo.

Det kompliserte elementet i denne strategien er ikke å forklare lokasjon og funksjon, men snarere å finne en balanse i hva som skal forklares. Det er her mange går i fellen. Ofte som et resultat av at det finnes en eller flere ildsjeler som med de beste intensjoner ønsker å forklare mest mulig.

Det er også en risiko for at en komplisert navnestandard mister sin hensikt. Dette kan skje når det ikke tas høyde for miljøendringer. Et eksempel på dette kan være at to datasenter slås sammen og man har benyttet variabler for disse i servernavn.

Det finnes ingen fasit eller mal for en god eller dårlig standard. En ting som passer bra for i en organisasjon kan fort bli en fadese i en annen virksomhet. På generelt grunnlag holder undertegnede en knapp på den enkle varianten med server001. Dette fordi den virker i alle miljø og vil aldri bli utdatert. Øvrig informasjon om selve tjenesten kan lagres separat i en et dokument, katalogtjeneste eller lignende. Noen vil også argumentere for at denne strategien er best i forhold til sikkerhet. Dette fordi man eksponerer ingen opplysninger om serveren ut i fra navn.

Hva er Cloud Computing?

Cloud er ikke det nye begrepet for Internett. Selv om Internett er et nødvendig fundament for cloud. Cloud er mer enn Internett. Cloud er der hvor man kan benytte seg av teknologi når man trenger det og for den tiden en ønsker. Cloud kan være både software og infrastruktur.

Tenk deg følgende eksempel: Et firma kjøper opp en tomt og bygger en stor blokk med mange leiligheter på denne tomten. Deretter leier de ut leilighetene. Du får lov å flytte inn og ut når du vil. Og du betaler bare for den tiden du bor i leiligheten. Enkelt sagt fungerer cloud omtrent på samme måte. En cloud leverandør leier ut servere, lagring og andre tjenester du finner på et datasenter.  Du betaler etter bruk. I tillegg får du lov å skalere opp umiddelbart ved behov og kanskje enda viktigere er muligheten for å skalere ned når du ikke trenger så mye ressurser lenger.

Cloud Computing er ikke noe nytt fra teknologisk synspunkt. Men fra et forretningsmessig ståsted introduserer det en helt ny måte å tenke på. Den viktigste grunnen for å velge cloud istedenfor å bygge ut sin egen IT infrastruktur er ikke teknologi, men økonomien i dette.  ”Betal for hva du bruker” modellen i Cloud Computing er i mange tilfeller billigere enn ”Betal for alt på forhånd” modellen.  

Her er noen kriterier som kjennetegner en typisk cloud tjeneste:

• Tjenesten er tilgjengelig via en webleser eller web tjeneste API
• Man betaler etter bruk
• Skalerbar
• Mulighet for selvbetjening

Hva med sikkerhet?

Et av områdene som kritikerne av cloud ofte nevner er sikkerhet. Det å plassere data inn i cloud uten å ha kontroll på servere/disker som det blir lagret data kan for mange virke skummelt. Realiteten er at cloud kan lages like sikkert og til og med sikrere enn ens eget tradisjonelle datasenter.

Før man benytter seg av cloud, er det viktig at:

• Man sjekker gjeldende lover, regler og standarder
• Man setter seg inn hvilke sikkerhetssystemer forskjellige cloud leverandører kan tilby.

Til slutt…

En spredning av cloud krever at lover og regler fornyes og tilpasses mulighetene Cloud Computing åpner for. Jeg tror virksomheter litt etter litt flytter tjenester til cloud. IT miljøer vil bli hybride. Det vil si at virksomheter bygger seg en ”intern” cloud som man eier selv, mens man flytter enkelte tjenester til en ”ekstern” cloud. Og dette er bare begynnelsen…

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?

I Crossing the Chasm foreslår Geoffrey Moore en mal for å lage visjon som jeg selv har hatt mye hell med:

• For <en målgruppe>
• Som har <et behov eller en mulighet>
• Så er <produktnavnet> et <type produkt>
• Som <har en god grunn til å like>.
• I motsetning til <viktigste alternativ>
• Har vårt produkt <viktigste differensiator>

Formen er ment brukt til å beskrive produkter, som for eksempel “For skogbruksansvarlige på fylkesmannens kontor som skal forvalte skogsprosjekter så er skogsforvaltningsløsningen et regnskapsystem som gir kontroll og oversikt over regnskapet. I motsetning til den gamle versjonen av systemet gir vår løsning støtte for fullstendig elektronisk saksbehandling.”

Jeg har også brukt den til workshops og andre aktiviteter. Når jeg avholdt en Scrum-workshop startet gruppen med å utarbeide følgende visjon: “For nye og litt erfarne Scrum Mastere som ønsker å bli bedre Scrum Mastere så er Iterasjon-0-workshoppen en gruppeaktivitet som gir konkrete tiltak til aktiviteter. I motsetning til å lese en bok gir denne aktiviteten mulighet til å utveksle erfaring med andre som har samme rolle.”

Slik går jeg fram for å hjelpe en gruppe med å komme fram til en visjon:

1. Først bruker jeg fem minutter på å forklare formatet og hvorfor vi gjør oppgaven
2. Jeg deler gruppen opp i arbeidsgrupper på 3-4 personer. En arbeidsgruppe mister noe når det blir mer enn 4 personer
3. Hver gruppe får ti minutter på å fylle ut formatet over. Dersom det er mye gode diskusjoner i gruppene lar jeg dem gå fem minutter over tida.
4. Jeg går gjennom malen og ber alle gruppene lese opp for forsamlingen hva de svarte på hvert punkt. For hvert punkt spør jeg åpent “hvilket svar var best?” Det nominerte beste svaret skriver jeg på tavle eller flipover. Dette tar cirka ti minutter.
5. Vi avslutter workshopen med en liten oppsummering av hva folk fikk ut av øvelsen.

Totalt får man en brukbar, felles visjon for en gruppe på under en halv time. Som en bonus blir gruppa som helhet litt bedre kjent med hverandre.

1. Vær god til å søke etter og tilegne deg informasjon raskt. Hvem har ikke sittet i møter der navn eller tre bokstavs forkortelser blir kastet i mot deg med største selvfølgelighet. Har du ikke hørt om det? Er du helt utdatert eller? Det er flere enn en gang man henter seg inn med et godt søk på internett mens bombardementet pågår. Konsulenttriks kaller noen det, jeg kaller det overlevelsestaktikk. Det er helt umulig å ha full oversikt over alt alltid. Mengden informasjon er simpelthen for stor.
2. Aksepter at verden endrer seg raskt, og vær åpen for nye og andre innfallsvinkler enn din egen, vær pragmatisk. Et eksempel: Noen insisterer fortsatt på at bunnposting er tingen i e-post, og argumenterer gjerne heftig for det. Dette til tross for at de aller fleste topp-poster, de fleste klienter viser tråden for emnet og mobiltelefonklienter bare viser toppen av mailen. Vedkommende som har skrevet har lagt sitt svar under noe du for lengst har lest. Det fremstår som unødvendig nerdete.
3. Basiskunnskap består. Lesing og matte er kanskje de viktigste av alle basiskunnskaper. Dette danner selve fundamentet for punktene over, så her gjelder det å være god. Læreplanen i den norske grunnskolen i dag er faktisk veldig lik den som ble laget i mellomkrigstiden på 1930-tallet. Sirkelen er fortsatt rund, linjen er fortsatt rett. Bokstavene ordnes ofte i alfabetisk rekkefølge (alfabetet begynner ikke med QWERTY…) og er de samme som før. Det er her kløften i samfunnet skapes, de som er flinke til å lese og liker å lese, og de som ikke liker å lese eller er dårlig til å lese og faller av skolen. Fatt mot, det er mulig å øve på hurtiglesing.
4. Vær kildekritisk og gjør deg opp din mening. Mange journalister er så hardt presset at de ikke har tid til å undersøke det de skriver. Dersom artikkelen bærer preg av å være markedsføring så er den gjerne det. Ofte kan også økonomiske, politiske eller personlige meninger ligge bak. Kanskje sympatiserer også journalisten med budskapet og det blir enda mer farget. Forsøk å finne en journalistisk artikkel som er negativ til Apple, første treff på Google er wikipedia.
5. Niche thyself. Oversatt betyr dette noe sånt som «finn din nisje». Ordene tilhører Guy Kawasaki og kommer fra boken ”the art of the start”. Han sa det om oppstartsbedrifter. Jeg mener det er minst like sant om fagpersoner. Kan du veldig mye om et smalt felt som er relevant og etterspurt, er du sikret jobb – i hvert fall en stund, til det du kan ikke lenger er etterspurt. Og så må du finne deg en ny nisje. Uttrykket burde kanskje modifiseres litt – Niche thyself, and again, and again.

 En bør altså være god til både å lære og å huske. Læring har imidlertid blitt mye viktigere enn husking i kunnskapssamfunnet enn hva det var i industrisamfunnet. Det er rett og slett komplett umulig å huske og kunne alt som er tilgjengelig. Er man lykkelig med det man vet og forberedt på å lære noe nytt går det som regel bra. Hvis ikke, google fungerer på iPhone under bordet også.

Det var mine topp fem overlevelsespunkter i kunnskapssamfunnet. Har du andre forslag til punkter?

Hvis man stiller de samme menneskene spørsmålet om hvordan antivirus oppdateres i virksomheten, kommer det uten unntak helt andre svar. Det er helt andre lover og regler som gjelder for antivirus. Dess oftere antivirus definisjonsfilene oppdateres, jo bedre er det. Det kan i hvert fall tyde slik på svarene man får. Det er ikke uvanlig at antivirusdefinisjonsfiler oppdateres opptil flere ganger per døgn i virksomheten. Dette er for så vidt helt greit, men det er ikke dette punktet som skiller oppdatering av antivirus fra andre typer oppdateringer. En ny antivirusdefinisjon, testes sjelden eller aldri i virksomheter før den slippes i produksjon. Det synes som et utstrakt mål at oppdateringer av antivirus skal ut så raskt som overhode mulig.

Hvorfor er dette et problem?

De aller fleste leverandører av antivirusprogramvare har ved en feiltagelse sluppet oppdateringer som har ført til at legale filer feilaktig identifiseres som virus. Noen ganger går dette bra, fordi virksomhetene ikke rekker å oppdatere sine egne kjernesystemer før den ondartede definisjonsfilen trekkes tilbake fra leverandør. Andre ganger får dette katastrofale følger ved at for eksempel kritiske tjenester og operativsystem stopper i det oppdateringen blir gjeldende i et miljø.

Virksomheter er i dag så redd for et virusutbrudd at antivirustjenestenes definisjonsfiler oppdateres for ofte og ukritisk. I praksis spiller mange russisk rullett med sitt produksjonsmiljø fordi man unnlater å teste definisjoner i forkant av en oppdatering. Ved hjelp av simple rutiner som allerede finnes i forbindelse med oppdateringer av annen programvare, kan risikoen for at antivirus blir virus elimineres.

Som en oppsummering på konferansen presenterer Kuppinger Cole de fem viktigste trendene innenfor IAm, GRC og Cloud computing. Nytt av året er at årets konferanse er slått sammen med Cloud Computing som virkelig er en het potet i Europa nå om dagen. Alle innlegg fram til nå har kommet inn på temaet, og det er stor spenning relatert til dette temaet som er upløyd mark. De viktigste trendene slik de blir formidlet er bl.a. en økende grad av justering mellom virksomhet og IT og evolusjonen mot et hybrid IT miljø bestående av et godt administrert miljø med en blanding av både interne og eksterne IT tjenester. Her er de heteste trendene , oversatt etter beste evne i tilfeller av manglende norske uttrykk, oppsummert fra konferansebrosjyren:

Identity and Access Management (IAM)

1. Mer fleksibilitet i arkitektur
   IAM-arkitektur er i endring. Den klassiske monolittiske tilnærmingen med provisioning som kjerne er kun en av flere arkitekturer som vurderes av integratører og kunder. Økende fleksibilitet i arkitekturer, samt integrasjon mot IT tjenester og virksomhetsportaler med sstøte for flere forsyningsverktøy blir mer og mer en realitet. Det hjelper også kunder med å implementere IAM raskere, biligere og mer spisset enn tidligere.
2. Tilgangsstyring og forsyning blir mer integrert
   Tilgangsstyring, også kalt IAM-GRC, er blitt en standard i flere arkitekturer og implementeringer, og er plassert på toppen av brukerforsyningen. Det er en økende grad av integrerte tilnærminger, samt en utvidelse av foryningsverktøy i form av tilgangsstyringsverktøy med mer støtte for integrasjon mot flere forsyningsverktøy i tillegg til adaptere for direkte tilkobling til mål- og fagsystemer. KuppingerCole forventer at denne trenden vil fortsette, og da med flere opsjoner for kundene og at tettere integrasjon mellom ulike teknologier vil bli mer standard.
3. Allsidige autentiseringsmekanismer blir mer modent
   Allsidige autentiseringsmekanismer, da i betydningen muligheter for å fleksibelt bruke ulike autentiseringsmekanismer basert på vanlig mellomvare blir mer modent og implementeres av flere leverandører. Dette muliggjør gjenbruk av sterk autentiseringsteknologi, samt mulighet for å velge den mest hensiktsemssige teknologien for ulike grupper av brukere (f.eks. interne og eksterne brukere) og brukstilfeller. Kostnaden med sterkere autentisering vil bli redusert.
4. Føderasjon finnes der ute
   Føderasjon, et tema som er gjenstand for mye diskusjon, er blitt en realitet. Tilsutningsraten er økende og vil fortsette å øke. I stedet for at man diskuterer potensialet blir nå føderasjon implementert i prosjekter med virkelige tilfeller.
5. Økende tilslutning av IAM i mellomstore bedrifter.
   IAM har fram til nå kun vært interessant for store selskaper og organisasjoner, og spesielt organisasjoner med compliance krav, men blir nå i økende grad relevant for mellomstore organisasjoner som middel mot å beskytte seg mot data- og informasjonslekkasjer og etterlevelse av krav angående personvern. Leverandører med standardimplementeringer og lettvekter produkter vil helt klart tjene på dette.

GRC – Governance, Risk Management, Compliance

1. Fra punktløsninger til GRC arkitektur
   Det er i dag for mange GRC initiativ i organisasjonene. Det spås at dette vil endre seg mot at flere virksomheter tenker mer på en helhetlig GRC arkitektur før man investerer i egne punktløsninger. Dette vil hjelpe virksomhetene til å optimalisere de investeringene som gjøres.
2. Tilgangsstyring som et startpunkt
   Tilgangsstyring er en av de mest økende områdene innenfor IT. Det betraktes som et logisk startpunkt for GRC initativ. Selv om det kun dekker en liten del av It-kontroller, er disse viktige, nemlig de som omhandler tilganger, informasjonslekkasjer, lovverkt angående personvern, og opphavsrett og/eller åndsverk. Det forventes at flere selskaper vil fokusere på tilgangsstyring når de skal investere i IT-GRC.
3. Lukke sløyfen for tilgangsstyring
   Et aspekt ved utviklingen er at det i økende grad blir mer integrasjon med automatiseringsteknologi for avstemming, som lukker sløyfen for endringer i målsystemer for attestering og sertifiseringer som har hatt fokus fram til nå. Disse tilnærmingene av lukking av sløyfene som støtter ikke bare reaktive men også prevantive kontroller blir mer og mer standard i markedet for tilgangsstyring (Access Governance).
4. Virksomhets-GRC åpner opp for IT-GRC
   I dag er mange av de såkalte virksomhets-GRC verktøy (bedre definert som virksomhetsorientert GRC ) hovedsaklig fokusert på forretningssidens syn på risiko, f.eks. drifts og noen ganger strategisk risiko. Men, forretning er basert på IT-systemer. Derfor er ITrisiko og driftsrisiko tett relatert, og de automatiserte kontrollene for driftsrisiko er basert på på informasjon i IT-systemene. Av den grunn må desse to verdenene konvergere, som helt klart er en stor trend i dag. Kuppinger Cole forventer at muligheten for å støtte integrasjon mellom virksomhetsstyring og IT-styring vil bli en nøkkedifferensiator mellom leverandører.
   
5. Risikokonsepter blir innført
   Risiko er i økende grad forstått som et nøkkelkonsept for IT-ledelse. Risikokonsepter blir i økende grad støttet av verktøy og implementert i organisasjonen. Men, det er typisk i dag et syn på organisatorisk og strategisk risiko som er splittet fra synet på IT-risiko. Analyseselskapet forventer at dette sakte men sikkert vil endres.

Cloud computing

1. Fra taktikk til strategi
   Cloud computing flytter seg nå fra taktikk til strategi – fra opportunistisk bruk av eksterne tjenester mot en strategisk tilnærming for anskaffelse av tjenester som dekker både interne og eksterne tjenester på en konsistent måte. Utviklingen er obligatorisk for muligheten til en fleksible anskaffelse av tjenester samt for å minimere risiko ved å ta i bruk standardiserte tilnærminger for valg av tjenestetilbyder(e).
2. Hybride IT-miljøer blir standard
   Virksomhetenes miljøer for cloud computing vil i økende grad være hhybride, med en blanding av eksterne og interne tjenestetilbydere. For de aller fleste organisasjoner vil dette bli en langsiktig realitet, og det er faktisk en realitet i dag når vi ser på eksterne tjenestetilbydere som blir benyttet på mange områder som bl.a. webkonferanse, webhotell, samt SaaS applikasjoner.
3. Fokus på tjenester og ikke på at de er eksterne
   Med utviklingen fra en taktisk tilnærmingen mot standardisering vil tjenester bli kjernen i cloud computing – alle typer av tjenester og ikke bare eksterne tjenester. Evnen til å vellykket administrere IT er veldig avhengig av en konsistent tilnærming for anskaffelse og administrasjon av tjenester, uavhengig av hvor de kjøres. Dette vil i større grad bli forstått med resulterende endring av fokus fra få store og populære tilbydere av cloud computing mot endring av IT-strategi og ledelse.
4. Det blir mer fokus på sikkerhet enn tidligere
   På nåværende tidspunkt blir sikkerhet sett på som et tema innenfor og for skyen, i hvert fall delvis. Kuppinger Cole forventer en økende grad av kunnskap om virkelige sikkerhets- og styringsspørsmål, som helt klart er forskjellig fra dagens tåkete sikkerhetsbekymringer. Utviklingen vil gi organisasjoner bedre muligheter til å håndtere cloud risiko og bygge gyldige sikkerhetsstrategier for bruk av eksterne tjenester i skyen.
5. Mange nyetableringer, sammenslåinger og oppkjøp av selskaper
   På lik linje som i andre nye markeder innenfor IT er det mange nyetableringer i markedet for cloud computing, og flere vil komme. Gitt at det er mange nye trusler er det nok av plass for oppstarter. På den andre siden vil det bli flere oppkjøp av større leverandører som vil utvide og styrke sitt eget cloud computing tilbud.

Verden ser altså ut til å ble mer hybrid enn hva vi ser er vanlig i dag. Interne og eksterne brukere, interne og eksterne applikasjoner og tjenester må administreres og styres. GRC skal dekke dette. IAM må virke med alt sammen. Bevegelse mot en tilnærminger som må støtte denne hybride IT-verden, samtidig med sterk justering mot forretningsnærhet, blir kjernepunkter ITsjefen må forholde seg til. Dette er også i samsvar med hva spesialistene og leverandørene mener og tror også. Min egen vurdering og oppfatning av denne overfloden av informasjon og inntrykk er at Norge på mange områder ligger langt bak mange av landene her i Europa. Men jeg tror også at på mange av disse områdene kommer vi etter etterhvert som kundemarkedet modnes. We are all individuals… really? Det viser seg at vi ikke er så veldig spesielle med spesielle behov likevel hjemme på berget. Vi er derimot på mange områder hengende etter og har mer taktisk enn strategisk fokus.

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.

For noen år siden hadde jeg et massivt vektproblem. Problemet var ikke så stort at jeg hadde vanskeligheter med å komme meg igjennom dører, men jeg hadde definitivt et helseproblem. Jeg hadde ikke en gang en god medisinsk unnskyldning for min overvekt, som noen legitimt kan ha for sin størrelse. Sannheten var at jeg rett og slett bare elsket mat, og at jeg var for svak til å sette en stopper for denne kjærligheten. Men jeg enten forsto ikke, eller ønsket å innrømme at jeg selv var problemet. Jeg prøvde hver eneste slankekur som kom. Vekten min gikk selvfølgelig opp og ned som en jojo. Den nyeste slankedietten skulle alltid være løsningen. Virket ikke den ene, kastet jeg meg fort over den neste. Jeg ønsket at andres diettplaner skulle fjerne min overvekten. Jeg ønsket ikke å endre egne uvaner eller måten jeg oppførte meg på. “Kuren”, “dietten” skulle løse det for meg. Kjøp av junk food var utrolig lettvint, og nødvendig i en konsulents travle hverdag. Jeg overbeviste i hvert fall med selv om det…

For å gjøre en lang historie kort så vedvarte problemet. Investeringer i nye kostprogrammer løste ikke problemet mitt. Det tok flere år før jeg erkjente at det var jeg selv som var problemet, eller mer nøyaktig: at det var tankeprosessen min som var det egentlige problemet. Slankekurene representerte den reaktive meg. Jeg fokuserte på vektøkningen, i stedet for å fokusere på endring av uvaner og adferd som var årsaken til vektøkningen. Manglende viljestyrke og udugelighet til å erkjenne, eller vilje til å erkjenne, selve problemet… var mitt problem. En dag, med hjelp av personer rundt meg og andre tilfeldigheter, bestemte jeg meg for at min egen relasjonen til mat måtte bli endret. Tankeprosessen måtte endres. Mat skulle være middelet for målet som nemlig var overlevelse og god helse. Maten skulle ikke være målet i seg eller for seg selv. Jeg var nå på min vei mot vektreduksjon. Det var kun etter at jeg erkjente jeg hadde et problem samt endring av min tankeprosess for å adressere problemet, at slankekurer, verktøy og strategier virkelig kunne få effekten av tankeprosessen til å bli en virkelighet.

Nå må jeg først si at denne historien faktisk hverken er selvopplevd eller sann, og jeg har aldri hatt et vektproblem. Men vi kjenner vel til andre med lignende problem. Hva er da så moralen, og hva har IAM med dette å gjøre? Like sikkert som at en slankekur ikke vil løse slankerens problem over tid, vil heller ikke verktøy alene løse organisasjoners utfordringer og problemer med brukeradministrasjon og tilgangskontroll. Det nytter ikke å spise plaster når man har magesår. Det som virker er er en sammenhengende, strategisk, fokusert og godt planlagt innsats som er styrt av et velfungerende team.  Jeg er fristet til å si at dersom virksomheten ikke er forberedt på en IAM-suksess for hele virksomheten, bør virksomheten virkelig re-vurdere et IAM-program i det hele tatt. Jeg kaller det et program fordi det i realiteten er flere prosjekter som må foregå samtidig.

Bare så det er sagt så er teknologi og komplekse integrasjoner nødvendig og en viktig del av et IAM program, men det kommer seinere på den lange reisen. Dessverre er det slik at mange virksomheter først velger å starte med integrasjon eller anskaffelse av skinnende ny teknologi, og ignorere det som virkelig er avgjørende for IAM-programmets suksess, nemlig mennesker, krav og prosesser. Holdningen til disse virksomhetene er at på grunn av politikk- og budsjettutfordringer i et IAM-program, er det mindre risiko å fokusere på et verktøy som, dersom det mot alle odds går bra, avleder organisasjonens og ledelsens oppmerksomhet bort fra de interne problemene som virkelig er årsaken til at IAM feiler eller ikke tar av.

Forberedelser, forståelse,  god planlegging, og en klar forankret strategi er veien å gå for å komme godt igang med et IAM program.

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.

• Bug rapport: “Administrative kostnader” skal fjernes: Når vi beregner totalkostnaden til et veiprosjekt, inkluderer vi kostnaden av nyanlegg, ombygging, bruer og administrative kostnader. Når vi demonstrerte applikasjonen til brukerne våre, husket de plutselig at administrative kostnader er sjelden i bruk og burde egentlig fjernes fra applikasjonen. Endringen var enkel og det er usannsynlig at en bedre analyse på forhånd hadde kommet fram til samme konklusjon. Dette er den type feilrapport vi liker å få.
• Bug rapport: Ikke-effektuerte utbetalinger skal telle mot totalt tilgjengelige midler: Når vi sjekket om det var tilstrekkelige midler for å utføre en utbetaling, glemte vi å ta med de utbetalingene som var registrert, men ikke utført enda. Tilstandsovergangen av utbetalinger fra registrert til godkjent til utført var litt mer kompleks enn vi hadde forventet, og enhetstestene sjekket ikke tilstrekkelig med varianter. Vi burde ha funnet denne feilen med enhetstestene våre, men dersom vi aldri får feil av denne typen, kan det være en indikasjon på at vi er for nøye med testingen vår. Så feilen er helt grei. Spesielt ettersom konsekvensene for brukeren ikke var spesielt store
• Bug rapport: Perioder som starter i desember rapporterer IllegalArgumentException: Når vi beregnet neste måned, glemte vi å ta hensyn til at du kan ikke bare legge til én på månedsnummer. Neste måned etter desember er ikke måned 13! Dette var en slurvete feil og jeg tror den ble introdusert en gang når vi ikke parprogrammerte (fordi koden var så triviell, liksom!). Brukerne våre forstår at slike type feil kan skje, men vi må se nøyere på prosessen vår for å unngå slike feil i fremtiden.
• Bug rapport: Layout ser rotete ut i Internet Explorer: For å unngå noen tekniske problemer når vi skrev enhetstester for HTML’en vi produserte, fjernet vi midlertidig doctype-definisjonen fra webside-malene våre. Så glemte vi å putte definisjonen inn igjen (jada, et nytt eksempel der vi ikke parprogrammerte). Sidene så fortsatt fine ut i Chrome og Firefox, som utviklerne brukte for manuell verifisering. Men i Internet Explorer så websidene direkte kaotiske ut. Den tekniske konsekvensen av feilen var triviell, men feilen kunne lett ha vært unngått, dersom vi vi hadde testet med samme nettleser som brukerne våre. Noen av brukerne våre fikk dette håpløse førsteinntrykket av applikasjonen mens de hjalp oss å teste. Det var skikkelig flaut. Dette vil vi ikke at skjer igjen!

Det er litt vanskelig å definere hvilke bugs som gjør meg mest flau. Noen viktige faktorer er hvor vanskelig ville det vært for oss å unngå feilen og hvor stor konsekvens feilen har. Men andre faktorer påvirker også hvordan vi oppfatter en bug. Av feilene på lista over, så er den jeg er mest flau over kun en kosmetisk feil. Men siden dette var noen brukeres førsteinntrykk av applikasjonen, var det mye mer problematisk enn de særtilfellene vi ikke helt støttet.

Hva synes du gjør en feil mer eller mindre akseptabel?

Språket blir dessverre behandlet som den stygge andungen av mange utviklere fordi det tradisjonelt oppleves som knotete, skjørt og lite vedlikeholdbart. Slik trenger det ikke være!

Vi i Steria har utviklet et gratis, nedlastbart kurs som oppdaterer deg på dette området. Denne workshopen introduserer ferdighetene, teknikkene og verktøyene som gjør JavaScript-utvikling langt mer overkommelig enn tidligere. Alt materiale i kurset er fritt tilgjengelig til din egen bruk.

Du kan bruke foilene, forelesningsnotatene og øvelsene som personlig studiemateriell. Du kan også holde kurset som en formell workshop sammen med kollegaer eller kunder. Workshopen tar omtrent en halv dag (3-4 timer) når det gjøres skikkelig – beregn halvannen time forelesning, minst halvannen time praktiske øvelser.

LAST NED HER

(Inneholder slides, forelesningsnotater, øvelser, løsninger, eksempler, verktøy. Utgitt under en Creative Commons Attribution 3.0 lisens. Du kan bruke, endre og dele det fritt, så lenge du krediterer opphavsmannen.)

Hvis du ikke har kapasitet til å kjøre kurset selv kan du ta kontakt med Steria; vi kan holde kurset i dine lokaler, i og rundt Oslo.

La oss avslutte med en smakebit. Filmklippet under illustrerer et av temaene som workshopen tar for seg, nemlig testdrevet utvikling i JavaScript. Enjoy!

Det finnes mange måter å håndtere mengden av passord på. Klassikerne er lapper og lagring i tekstfil (et lurt sted). En annen velkjent taktikk for å slippe å notere ned passordet er rett og slett å benytte samme passord overalt. Jeg har en god venn som har den strategien. Det finnes ikke et system som han har tilgang til hvor passordet er noe annet enn melk10 eller en nærliggende variant (Les: melk10mars).

For inntil få år siden hadde undertegnede en passordstrategi som i sin helhet var lagret i den biologiske harddisk. I praksis var det to utfordringer i denne strategien som gjorde at ting ble uoverkommelig.

Det første problemet var lengden på passord. Strategien og systemet var basert på lange passord. Normalt over 15 karakterer, et tall som ikke er helt tilfeldig. I det et passord passerer 15 karakterer i et Windows domene kan ikke domenekontrollerne lagre passordet i det svake LanManager (LM) formatet. En av feilene i systemet er at det finnes påfallende mange tjenester som ikke tillater lange passord. Et eksempel på det er finn.no som har en begrensning 12 karakterer. Det holdt derfor ikke å ha en strategi for å lage lange unike passord, jeg måtte også ha en plan for hvordan jeg skulle håndtere alle restriksjoner.

Utfordring nummer to knyttet seg til metadata. En ting er å huske passord, men hva med brukernavn? Utfordringen ledet faktisk til et problem. Jeg var til stadighet nødt til å få tilsendt innloggingsdetaljer via e-post. Ikke fordi jeg hadde glemt passord, men fordi jeg ikke husket brukernavn. Typisk for situasjonen er at man mater inn alle sine e-post adresser i tur og orden helt til tilbakestillingstjenesten bekrefter at kontoen finnes og nytt passord er sendt. Sammen med dette får man også tak i alle andre detaljer knyttet til kontoen, slik som brukernavn.

Strategien ble som nevnt tidligere forkastet for noen år siden. Godt utstyrt med personlig stolthet, satt det som vanlig langt inne å gjøre en adferdsendring. Dette på tross av at alle utenforstående faktorer tilsa at dette var det eneste riktige å gjøre. Jeg skal derfor ærlig innrømme at skifte av strategi var godt hjulpet av det faktum at jeg ble introdusert for et fantastisk redskap. Verktøyet ble benyttet i en driftsavdeling hos en av mine kunder. Samtlige passord og innloggingsdetaljer ble oppbevart og lagret i ulike databaser ved hjelp av dette verktøyet. Det finnes helt sikkert et utall applikasjoner som gjør nøyaktig samme jobben, men det var første gang jeg så et slikt produkt.

Produktet som jeg sikter til heter KeePass. Det er ikke så ofte man får den følelsen med programvare, men produktet bare stemte et hundre prosent. Det var så tydelig at de som hadde lagd produktet forstod hvilke utfordringer som er knyttet til oppbevaring av brukernavn og passord. Sikkerheten rundt produktet er god. KeePass støtter AES og SHA-256 bit kryptering og alle data lagres i en flat databasefil. Det er heller ikke behov for å installere noe på klienten hvor KeePass skal benyttes. En eksekverbar fil er alt som skal til. KeePass er et gratis sourceforge prosjekt som du finner på http://keepass.info. Applikasjonen utviklet seg raskt til å bli en av mine viktigste og mest kjærkomne verktøy for å overleve i jungelen av passord. Hvor er dine passord?
Kilder:
http://research.microsoft.com/en-us/um/people/cormac/papers/www2007.pdf

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)

• Påpek noe positivt: Etter kurset fikk vi en mail fra en av deltagerne som sa “takk for kurset, det var veldig bra”. Det gjorde meg bevisst på hvor sjeldent vi gir og mottar skryt uten at det er et “men…” hengende rundt hjørnet og hvor motiverende det er når man faktisk får det.
• Vær konkret: Dersom du sier “foredraget var litt uklart”, gjør du mottakeren av kritikken en bjørnetjeneste. Uten at du påpeker noe konkret er det vanskelig for mottakeren å gjøre noe med det. Dersom du i stedet kan si: “Eksemplene gikk litt fort”, så er det lettere å gjøre noe med det.
• Foreslå en forbedring: I stedet for å peke på hva som var dårlig, kan du finne rom for å gjøre det bedre?
• Motiver forbedringen: I stedet for å bare gi et forslag til forbedring, kan du forklare hvordan endringen vil forbedre foredraget. Det tydeliggjør at du ønsker å hjelpe, samtidig som du anerkjenner at det er den som mottar forbedringen som tar den endelig avgjørelsen.

Som et eksempel på prinsippet, sa jeg under kurset til min med-instruktør: “Du Ram, ‘å bli en bedre presentatør’ høres litt klønete ut. Dersom du i stedet sier ‘å bli flinkere til å presentere’, så tror jeg setningen vil flyte bedre.”

Er du bevisst på å gi gode tilbakemeldinger? Hvilken tilbakemelding kan du gi meg når det gjelder denne artikkelen?

“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

Hvem?

Det viktigste når du skriver en blogpost er å være bevist på hvem dine lesere er. For denne artikkelen gjorde jeg meg følgende tanker:

• Hva er leserens forhold til tema? Jeg regner med at du som leser blogger litt eller tenker på å starte å blogge.
• Hva tenker leseren om tema? Jeg regner med at du synes det er vanskelig å komme i gang med bloggingen.
• Hva får de ut av å lese blogposten? Etter å ha lest posten vil jeg at du skal føle deg mer i stand til å skrive dine egne blogposter.

Hva?

Når du vet hvem du henvender deg til, er det viktigste å jobbe med innholdet og strukturen.

• Struktur: For hvert avsnitt vil du miste 5% av leserne (for å trekke et tall ut av lufta). Skriv det viktigste først
• Språk: Bruk aktivt språk som henvender seg direkte til leseren. Et eksempel på aktivt språk er: “Bruk aktivt språk som henvender seg direkte til leseren”
• Eksempler: Det er vanskelig å formidle abstrakte ideer. Eksempler er enklere.

Hvordan?

Når jeg starter med en blogpost, starter jeg nesten alltid med å kladde på papir. Jeg skriver strukturen ned, river i stykker papiret og skriver den ned på nytt. For meg fungerer det veldig godt å skrive på papir for å bearbeide tankene. Når jeg tar fram datamaskinen, blir jeg distrahert av verktøyene.

Mine mest populære artikler er de som der jeg har fått mye innspill av andre før jeg har publisert artiklene. Send utkast til artikkelen til folk du stoler på og be om konstruktiv tilbakemelding. Konstruktiv tilbakemelding er konkret og spesifikk: For eksempel: “Dersom blogposten hadde brukt punktlister også i siste avsnitt hadde den virket mer helhetlig uttenkt”. Personlig liker jeg best å dele utkastene mine med andre via Google Docs, framfor å maile vedlegg frem og tilbake.

Spre ordet via de kanalene du kommuniserer med: Pass på at bloggen har en RSS-feed. Bruk twitter, yammer, facebook, linkedin etc for å spre ordet. Ikke glem den gamle traveren email, heller (men for guds skyld, ikke spam folk!)

Hvorfor?

Som mennesker ligger trangen til å kommunisere i vårt DNA. Når jeg er entusiastisk om noe, føles det riktig å dele det. Å nå andre bekrefter vår egen eksistens.

Blogito, ergo sum!

Fredag 5. februar viste vi følgende foredrag:

• Alexis Ohanian: How to make a splash in social media (Mr Splashy Pants)
  Et av de korteste foredragene vi har sett, men også ett av de mest effektive. Ohanian forteller deg hemmeligheten til å lykkes i sosiale medier gjennom en sann historie.
• Rory Sutherland: Life Lessons From an Ad Man
  Underholdende og tankevekkende foredrag som vil få deg til å se markedsføring i nytt lys.
• VS Ramachandran: The neurons that shaped civilization
  Utsagnet om at alle mennesker er koblet sammen viser seg å være langt sannere enn vi først trodde. Det er faktisk bare huden som skiller oss. Hør om de fascinerende nevronene som kobler oss sammen.
• Robert Full: How engineers learn from evolution
  Du skulle ikke tro at et foredrag om føtter kan være fascinerende, men jo det kan det være! Se hvordan neste generasjon med roboter har dramatisk bedre fremkommelighet fordi forskerne har studert naturen og etteraper naturens konstruksjoner.
• Pranav Mistry: The thrilling potential of SixthSense technology
  Dette er den beste teknologidemoen du vil se i 2010. En ny vri på såkalt “augmented reality” — og teknologien er til og med rimelig!
• Ariely performs experiments on pain and immorality
  Fascinerende på flere plan. Ariely tar for seg både smerte og umoral. Svært interessant om hvordan og hvorfor folk jukser og hvordan tradisjonell økonomisk teori kommer til kort for å beskrive den irrasjonelle oppførselen rundt juksing.

Hva synes du om disse foredragene? Og har du tips til andre gode foredrag vi bør vise?

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).

I en ny undersøkelse som ble presentert i en pressemelding 26.1 går det fram at hver tredje norske virksomhet vil bruke sosiale meder i aktivt innen to år. I en tilsvarende undersøkelse før sommeren 2009 svarte 6 prosent av de norske it-sjefene at sosiale medier brukes som strategisk virkemiddel i deres bedrift. I høstens undersøkelse har andelen steget til 10 prosent. Dette viser at det er en endring i innstillingen, og det er stor grunn til å anta at reelt vil flere enn én av tre virksomheter faktisk bruke teknologier eller ideer fra sosiale medier aktivt innen 2012. Jeg mener at for de veien dit vil i de fleste tilfeller gå utenom de høyt profilerte tjenestene Twitter og Facebook.

Facebook og Twitter har åpnet for mange mye muligheter for markedsføring, kundekontakt og kommunikasjon (selv om Norsk Møteforum kom fram til noe annet i sin undersøkelse). Facebook blir av de fleste brukere ansett som en privat arena, mens Twitter fortsatt ikke har blitt så mye mer enn et nisjested for spesielt interesserte (ref nye tall). Jeg vil derfor påstå at i den profesjonelle verden er Facebook og Twitter av liten betydning utenfor marked- og kommunikasjonsavedlingene. For de andre delene av organisasjonene ligger gevinstene helt andre steder.

Folk flest har lært seg bruken av Facebook og ideene til web 2.0. La oss nå ta disse kunnskapene inn i bedriftene og utnytte dem i vårt daglige arbeid som for eksempel i produksjonsprosessen, i kunnskapsforvaltningen eller i prosessforbedringene.  Heldigvis er trendene allerede på vei inn i næringslivet, og det finnes mange gode eksempler som kan være til inspirasjon.

På T-banens nye driftsentral har de byttet ut gule lapper med mikroblogging. Foto: T-banen

Markedsplassen Finn er ett eksempel som har hentet inspirasjon fra sosiale nettsteder til sitt egenutviklede system ”FinnOpp”, som skal stimulere til ideskaping hos selskapets egne ansatte. Et annet eksempel er T-banen som bruker blogg som hjelpemiddel i overvåkning av trafikken. Flere kommuner har tatt i bruk sosiale nettsteder hvor brukerne kan melde om feil i nærområdet sitt. Her i Steria bruker vi Yammer, blogg, wiki og SharePoint aktivt innenfor kunnskapsdeling, erfaringsutveksling og i prosjektarbeid. Dette er gode eksempler hvor virksomhetene har tatt tak i enkelte viktige områder, og forbedret disse ved hjelp av sosiale medier.

Når det gjelder teknologi så skjer det også mye om dagen. Med SharePoint 2010 som lanseres senere i år tar Microsoft et steg videre inn i web 2.0 verdenen. I denne versjonen har elementer som grupper, mikroblogging, tagging, scoring, og forbedret søk blitt tatt inn som en del av løsningen. Dette er en trend som også gjenspeiles i løsningene til andre store aktører også som Lotus Connections fra IBM og Documentum fra EMC. I tillegg finnes det etter hvert at hav av mindre leverandører som leverer nisjeprodukter, som f.eks mikrobloggingstjenesten Socialcast, innovasjonshåndtering fra Induct og wikiløsningen Confluence.

Ettersom produktene blir mer modne, kunnskapen bedre og erfaringene flere er det stor grunn til å både tro og håpe at sosiale medier vil spille en aktiv rolle for langt flere enn én av tre bedrifter i 2012!

Det er lenge siden våren 2008 da Steria tok de første skrittene når det gjaldt bruk av sosiale medier. Første fase var utprøving av den nye teknologien. Internt testet vi ut bedriftswiki. Eksternt begynte vi å følge mer bevisst med på hva som skjer der ute på nettet, og spesielt på sosiale nettsteder. Ordinær presse hadde vi selvfølgelig overvåket lenge.

Neste skritt var å bli aktiv på Twitter og LinkedIn. Det ble opprettet Twitter kontoer som for eksempel STERIAlynkurs. Internt begynte vi å teste ut mikroblogging med Yammer. Yammer har i dag har utviklet seg til å bli et nyttig verktøy for mange Sterianere som kompletterer allerede eksiterende verktøy som internwikien og SharePoint-portal. Mer om Yammer kan dere lese om i et innlegg på samhandlingsbloggen.

Som en kompetansebedrift har kunnskapsdeling alltid vært viktig for Steria. Med Sterk blanding får de ansatte i Steria en ny kanal som er enkelt tilgjengelig for alle. Den går rett til kjernen på hovedprinsippene for sosiale medier, nemlig deling, respons og brukergenerert innhold. Sterk blanding skal være en arena hvor Sterianere kan dele med hverandre og med resten av verden. Det blir spennende å følge med på hva som skjer!

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.

Lykke til med ditt testbare prosjekt!

Uten mer om og men, poster jeg en video her av hvordan jeg liker å jobbe med tester for å drive fram “kravene” til en applikasjon og refactoring for å forme designet til applikasjonen. Se spesielt rundt 11:30 minutter inn i videoen hvor jeg refactorer inn et regelmotordesign i en fungerende løsning.

Oppgaven kalles “Fizz buzz kataen”. Den går ut på å generere en sekvens av nummer der hvert tall som er delelig på 3 erstattes med “fizz” og alle tall som er delelig på 5 erstattes med “buzz”. Så starten blir “1, 2, fizz, 4, buzz, fizz, 7, 8, fizz, buzz, 11, etc.” Seks minutter inn i kataen endres kravet (og musikken!): Nå skal man kunne programmere inn hvilke erstatningsregler som gjelder. Som eksempel bruker jeg at “tall delelig med 2 skal erstattes med ‘coconut’ og tall delelig med 7 skal erstattes med ‘banana’”.

Takk til Emily Bache for inspirasjon til oppgaven.

Fizz buzz code kata av Johannes Brodwall på Vimeo.

Jeg bruker IntelliJ IDEA Community Edition på Windows Vista (!) til å løse oppgaven. Videoen er filmet med BB FlashBack Express (som er gratis), konvertert til AVI med Windows Media 1 codec og lastet opp til Vimeo.

Denne blogposten var originalt publisert på engelsk på min personlige blog.