Helgen viste meg noen av de beste mulighetene man har til å utnytte open space. Her er et utvalg av sesjoner og hva som gjorde dem bra:

• På min første sesjon “Certified Scrum Dev exercises” ba jeg om ideer og innspill til hvordan å gjennomføre et kurs for folk som vil bli bedre utviklere. Det var bare seks personer som møtte opp og vi hadde en ganske kort diskusjon, før jeg spurte de som var til stede om de hadde lyst til å prøve en praktisk workshop jeg hadde lest om. Så brukte vi 30 minutter der vi programmerte “Elephant Carpaccio”. Jeg hadde lest litt om øvelsen før workshopen og jeg har selv deltatt på øvelsen for et halvt år siden. Ut over det hadde jeg ikke gjort noen forberedelser.
• Jeg deltok på Olaf Lewitz sin open space om “Scoping techniques“. Olaf tegnet opp et sett med teknikker på en flipover: Feature Injection, BDD, User Story Mapping, Effect Maps. Noen i publikum spurte “kan du fortelle litt mer om feature injection,” og så tegnet Olaf opp en skisse som demonstrerte arbeidsflyten. Noen foreslo andre teknikker, for eksempel så forklarte jeg modellen Evo. Olaf skisserte det jeg beskrev på en flipover. Olaf hadde forberedt seg med noen tanker på forhånd om hvilke teknikker han ville ha med seg og hvordan han kunne fremstille disse.
• Karianne gjennomførte en liten open space sesjon med tittelen “Refactoring dojo“. Hun hadde tatt med et kodeeksempel hun hadde brukt før og en PC, og de som møtte opp gjorde forbedringer i koden. Karianne koblet sin PC opp på en projektor og det gikk på omgang hvem som satt ved tastaturet og hvem som observerte og kommenterte det som ble gjort.
• Jeg hørte fra noen som hadde deltatt på Joh og Simon sin open space “Breaking big rocks“. Her hadde facilitatorene forberedt et nøye planlagt opplegg: De beskrev et eksempel på et “stort problem” (“big rock”). Så delte de opp gruppen i grupper på 3 og ba hver gruppe komme opp med noen store problemer på post-its. De hang opp problemene på en flipover. Så ba de gruppene om å velge et problem hver og diskutere hva som gjorde det stort. Når gruppene hadde diskutert, samlet de sammen beskrivelsene og demonstrerte hvordan de problemene folk hadde samlet inn egentlig var veldig like. Jeg fikk inntrykk av at Joh og Simon hadde brukt litt tid på å planlegge sesjonen og bestemme seg for hvilke spørsmål de skulle stille til gruppen.
• Jeg deltok på en annen sesjon med Olaf Lewitz – “Lean procrastination“. I introduksjonen fortalte Olaf at han hadde holdt en keynote med denne tittelen for et par uker siden. Vi hadde en projektor tilgjengelig, så deltagerne spurte om han kunne gå gjennom presentasjonen for oss. Resten av sesjonen ble en uformell presentasjon med slider.
• Jeg foreslo en kvelds-open space med tittelen “how to fix devs“. Jeg introduserte med “vi klager alltid over prosjektledere, kunden, produkteiere, arkitekter osv. Nå vil jeg klage litt over (oss) utviklere”. Vi hadde en liten diskusjon og jeg presenterte noen tanker om hvordan vi burde justere på rammene for utviklere, for eksempel at “i stedet for at utviklere gir estimater for oppgaver, hva om produkteier gir budsjetter for oppgaver”. Jeg hadde tenkt mye på temaet før open space og fikk masse bra feedback på hvilke av disse tankene som virket fornuftig som jeg kan ta med meg videre.
• I en tidsperiode der jeg ikke fant en sesjon som jeg inspirerte meg, gikk jeg rundt og hørte på litt forskjellig. Jeg ble sittende på slutten av en sesjon som het “Definition of Agile Coaching“. I løpet av sesjonen hadde gruppen produsert denne definisjonen: “Agile coaching is a 100% client-focused engagement which enables continuous improvement, because the client owns aligned goals and purpose across organisational levels and the people doing the work define the steps towards those.”
• Jeg holdt en siste open space på søndag, denne om “non-violent communication“. Jeg introduserte med “jeg har lest en bok som ga meg masse tanker jeg synes var spennende, jeg vil gjerne diskutere dette med dere”. Diskusjonen var ustrukturert og springende, men det var mange som deltok og alle følte at de både bidro og fikk utbytte av alle de forskjellige diskusjonene. Jeg noterte meg noen ord på et par flipovers, men notatene var ikke mulige for noen som ikke hadde deltatt å forstå. Diskusjonen skapte mye tanker om hva vil det egentlig si å tvinge noen i en diskusjon. Vi fikk en positiv atmosfære i gruppen som ga en fin avslutning på helgen.

Om jeg skal trekke noen konklusjoner: Man kan komme til en open space med forskjellig grad av forkunnskap og forskjellige forventninger. Du kan stille med med en ferdig presentasjon, en plan med spørsmål, en liste over relevante spørsmål og ideer, eller bare med et tema (som da jeg foreslo “non-violent communication”). Resultatet kan bli at man gjennomfører en øvelse sammen, produserer et resultat, kommer opp med en liste med ideer som folk kan sjekke ut etterpå eller at man bare har en hyggelig samtale.

Vellykkede open spaces kommer i mange størrelser og fasonger. Et av prinsippene bak open space er “whatever happens is the only thing that could have happened”. Eksemplene mine fra Agile Coach Camp demonstrerer dette prinsippet: Man kan komme til en open space med forskjellig grad av forkunnskap og forskjellige forventninger. Når gruppen får en sjanse til å forme innholdet, blir opplevelsen verdifull for alle.

På kick-off i år vil Steria feire “The Power of Sharing” ved å vie den faglige delen til Open Space. Her har alle som deltar anledning til å skape dialog om ting som interesserer dem. På en open space kan du ta opp ting du er flink til som du ønsker å dele, ting du ikke er flink til som du ønsker å lære, måter du ønsker andre endrer seg på eller hva enn som interesserer deg.

Praktisk fungerer det slik at deltagerne foreslår sine temaer ved oppstarten av open space. Du vil få ti sekunder på scenen å fortelle hva du vil diskutere og så får du plassere temaet i programmet som vi henger opp på en stor tavle. Når “din” sesjon starter er du ansvarlig for å ønske velkommen og etter det kan du lytte eller snakke så mye eller lite du ønsker. Du trenger ikke å forberede noe før en open space (men du kan om du vil). Alle diskusjonsgruppene vil ha flipover og noen få vil ha projektor.

Her er eksempler på ideer som andre har tenkt å bidra med på Sterias open space:

• ABC of ICT
• Slik kommer du igang med brukertesting
• Hvordan få til tverrfaglige løsningsteam i smidige prosjekter
• Hvordan få brukertesting inn i alle Sterias systemutviklingsprosjekter
• Hva bør en SharePoint-konsulent være?
• Hvordan bli en bedre leder og hvordan få en bedre leder
• Kommuniksasjonsstil: Er du grønn, gul eller rød
• Bli med og leke med CoffeeScript
• Skal vi bidra til et open source prosjekt?
• Sterias bidrag til FNs tusenårsmål
• The rise and fall of Intranets
• Trender og utvikling i IT-bransjen
• Kan en kontrakt være smidig?

Som deltager på open space er du ansvarlig for ditt eget utbytte. Så det er lurt at mange tenker litt på forhånd om hva de vil diskutere! Så gjør deg selv og dine medmennesker en tjeneste: Bruk ett minutt på å tenke på hva du kunne tenke deg å dele, å lære, å endre sammen med de du jobber med. Skriv gjerne en (uforpliktende) kommentar med et mulig tema.

Reduksjon i informasjonsmengden – bedre kvalitet og oversikt
Et av målene for opprydningen var en reduksjon i informasjonsmengden, slik at det er mulig å få bedre oversikt, både for redaktører og for besøkende på nettsiden. Det ble satt harde krav til hva slags informasjon som skulle kunne publiseres på de nye sidene. Samtidig ble webpublisering gjort mer sentralisert.

En ting som overrasket meg underveis i prosessen var hvor viktig de ulike avdelingene synes det var å få med mest mulig stoff om seg selv på de nye sidene. Underredaktørene la ned et betraktelig antall timer på telefon og e-post for å overbevise ansatte og beslutningstakere i organisasjonen om at all denne informasjonen ikke var like interessant for publikum. Kommunikasjonsjobben var minst like viktig som innholdsproduksjonsjobben.

Innholdsproduksjon tar tid
Innholdsproduksjon tar som regel lenger tid enn man tror. I følge innholdsstrategiguruen, Kristina Halvorssen er dette en svært hyppig årsak til at prosjekter blir forsinket. Arbeidet med innholdsproduksjon for Forsvaret.no var av avhengig av fagpersoner “ute i bruket”. Å samle inn webtekster, som skal være bedre enn de gamle, men mye kortere, er svært tidkrevende. Mange av tekstene ble derfor skrevet av redaksjonen og det ble flere runder med korrektur, sletting, godkjenning og omkalfatring før innholdet var klart til publisering.

Tusener av klikk spart
Utviklerkollegerne mine i Steria laget et smart script som gjorde at informasjonsstrukturen, som var laget i MindManager, ble importert i SharePoint og at sidene med tilhørende maler ble opprettet automatisk. Dette sparte webredaktørene utallige museklikk. Det var likevel ikke til å komme fra at publisering i SharePoint hadde sine utfordringer, spesielt i starten. Du kan lese mer om strukturgenerering i  presentasjonen SharePoint 2010 for Internet – Issues and solutions through a case study (Slideshare)  fra Norwegian Developer Conference tidligere i år.

Excel-oversikt og innholdsdugnad
En innholdsoversikt i Excel ble laget for de nye sidene. Kvalitet og eier av hvert innholdelement ble lagt inn. Dette var et godt oppfølgingverktøy for innholdsproduksjon i innspurten. Innhold ble skrevet på dugnad og det var mange bidragsytere.  

Forsvaret.no  var et kundedrevet prosjekt. Som konsulenter kunne vi dra videre til andre kunder da prosjektperioden var overstått. Forsvarets  webredaktør uttalte ved lansering at “det er nå arbeidet begynner”. Du, som er opptatt av webting, har kanskje oppdaget at Forsvaret.no har en helt tradisjonell venstremeny. Det er flere grunner til det, men det er en annen historie.

Eli Toftøy-Andersen er medforfatter av boken Praktisk brukertesting og  blogger til vanlig på brukskvalitet.no. Høsten 2011 holder hun workshop sammen med kollega Jon Gunnar Wold på  brukervennlighetskonferansen Yggdrasil 17-18 oktober og foredrag på Meetup for interaksjonsdesignere, IxdA 12. oktober.

Bloggposter fra brukskvalitet.no:
10 gode grunner til å gi avslag på publiseringsønsker 
 5 tips for brukertesting av innhold
Brukervennlighet – et folkekrav  

Andre relevante lenker:
SharePoint 2010 for Internet – Issues and solutions through a case study:
http://www.slideshare.net/jmkristiansen/ndc-presentationfinal

Innboksen som arbeidslivets kjellerbod:
http://sterkblanding.no/blog/2011/09/28/innboksen-som-arbeidslivets-kjellerbod/

I min kjellerbod er det veldig fullt rett til venstre rett innenfor døra, for det er så lett å løpe ned med noe jeg ikke trenger å ha stående fremme og lempe det der. Boden har reoler og to skap, men det er ofte jeg ikke tar meg tid til å finne den beste plassen for det jeg bærer ned.  Dette tar jeg ikke så  tungt, for jeg  finner stort sett det jeg leter etter senere. Men jeg har alltid intensjoner om å få ryddet ut av boden når borettslaget leier container.

For mange er innboksen en kjellerbod hvor man oppbevarer det som er kjekt å ha – gjerne rett innenfor dørterskelen uten å legge i mapper – og ettersom e-postene kommer til innboksen av seg selv fylles den enda raskere enn boden.

Hvis du bruker innboksen som arkiv fordi det er stedet med best struktur og best funksjonalitet for  søk og gjenfinning, så er det noe annet som er galt. Betyr det at det ikke finnes noen gode samhandlingsløsninger? Betyr det at du har en egen mappestruktur du ikke selv klarer å finne frem i? Betyr det at det er vanskelig å legge vedleggene som kommer med e-postene på rett plass.

E-post er så lett. Det er litt som kopimaskinene på 1990-tallet. Det ble så lett og billig å ta en kopi så man gjorde det for sikkerhetsskyld. Selv om mange arbeidsplasser har begrensing på størrelsen på innboksen, så er det ikke regler eller restriksjoner på hva man får lagre. Derfor tenker man at det er billig teknologi. Man hvis man spør den IKT-personen som har Exchange ansvar hva han eller hun synes, skulle han ønske at folk var litt flinkere til å slette e-post; særlig at folk kunne slutte å sende morsomme e-poster med store bilder som blir sendt til den ene kollegaen etter den andre og slik tar opp mye plass mens den vokser som celledeling. Akkurat som du ikke ønsker å måtte betale ekstra for å leie oppbevaringslokaler for esker du ikke husker helt hva inneholder, ønsker heller ikke IKT-avdelingen å betale for å ta vare på irrelevant informasjon.

Det finnes tekniske e-postarkiveringsløsninger for å avlaste Exchange servere og arbeidsplassen bør tilrettelegge med gode samhandlingsløsninger, men mye kan også gjøres med å forbedre egne rutiner.

Fem tips til høstdugnad i den digitale kjellerboden din:

1. Slett med en gang det som bare var til informasjon og som du aldri kommer til å få brukt for. Dette burde være selvsagt, men det er så lett å glemme.
2. Ha kontroll på mappestrukturen i innboksen. Sorter det du vil ta vare på over i mapper. Det er ikke lurt å ha for mange mapper, men prosessen å flytte e-post over i mappe gjør det bevisst på om du er interessert i å ta vare på den eller ikke.
3. Bruk lenker istedenfor vedlegg der det er mulig. De arbeidsplassene der man har gode samhandlingsløsninger er det bedre å dele lenker til dokumenter enn å sende dokumenter som vedlegg for å være sikker på at det er siste versjon man får se. Og privat er det like greit å sende lenker til digitale fotoalbum, som å sende bilde-filer som vedlegg.
4. Lagre de vedleggene som du kan få brukt for. E-post kan være en formidler av viktig informasjon. Hvis vi snakker e-post i jobb sammenheng, bør informasjonen overføres til et arkivsystem eller en informasjonshåndteringsløsning slik informasjonen blir virksomheten sin og ikke din.
5. Lag rutine av slettingen. Hvis du rydder e-posten sammen med morgenkaffen, før du går for dagen eller en gang i uken, blir det enklere å finne det du faktisk har brukt for

 Både du som enkeltperson og du som virksomhet har best av å ikke ha mye i innboksen!

Ville du ha brukt notepad til å skrive kode ?
Selvsagt (forhåpentligvis) ikke. Vi bruker IDE til programmering fordi det gir en sikrere og raskere prosess. Moderne IDE-er inneholder et arsenal av verktøy. En av disse er code templates. Jeg skal her gå igjennom hvordan man kan bruke de innebygde code templatene eller endre disse slik at de passer perfekt. Man kan også lage nye selv. Jeg vil her bruke Eclipse og Java som et eksempel. Code templates finnes derimot i flere IDE-er (som for eksempel InteliJ og Netbeans) og kan også benyttes på samme måte i andre programeringsspråk enn java.

Bruk de innebygde code templatene

Eclipse kommer med mange innebygde templates. Disse listes opp under Preferences-Java-Editor-Templates. For å aktivere templaten i koden trykker du “Ctrl-Space-Space”.

Skal du opprette en junit-test (og det gjør du vel en del ganger?) finnes det en template for å dette. Denne ser slik ut:

Her lages det en metode annotert med test. org.junit.Assert importeres statisk. Og cursoren settes inne i metoden. Det opprettes også en variabel (testname). Dette gjør at brukeren skriver rett etter genereringen fylles inn der.

Det er fullt mulig å editere på templatene hvis de ikke passer helt. Dersom man for eksempel bruker fest assert så trenger man ikke statisk import av org.junit.Assert. Det er bare å slette den delen.

Ta deg tid til å ta en titt på de innebygde templatene. Det er antgelig flere ting du gjør ofte som det finnes templates som gjør denne jobben lettere.

Lag dine egne templates

Man kan også lage sine egne templates. Her skal vi ta for oss to eksempler.

Template for equals metode

Vi skal her se på en template for en eguals metode (Jada, det finnes mange andre måter for å enkelt lage en equalsmetode, men dette er et eksempel)

Minst 99% av alle equalsmetoder starter med å sjekke at objektet er av riktig type. Siden klassenavnet varierer fra klasse til klasse (duh), bruker vi en variabel “enclosing_type”. Denne erstates med navnet på klassen vi er i. I tillegg caster vi deretter objektet til den aktuelle typen. Det er i tillegg lagt på en nullsafe equalsmetode som kan brukes til å sjekke de aktuelle atributtene. Vi har også tatt med en gyldig (men ikke veldig bra) implementasjon av hashCode slik at man oppfyller kontrakten mellom equals og hashcode.

Template for å generere en factory metode

Mange ganger er det nyttig å opprette en klasse med en statisk metode. Følgende template hjelper deg på vei her :

Som vi ser brukes det mye av de samme teknikkene som i equals templaten. Det som er nytt er bruken av variable. Variable er felt som brukeren kan editere på umiddelbart etter å ha kjørt templaten. Her bruker vi dette til å redigere på variabelnavnet (som jo varierer mye fra klasse til klasse). Feltnavnet brukeren skriver inn oppdateres tre steder:

1. I feltnavnet
2. I parameteren til metoden
3. I tilordningen på begge sider av likhetstegnet.

Disse templatene er bare eksempeler. I et hvert domene finnes det noe som gjøres mange ganger og er nesten likt. Tenk deg om. Antagelig finnes det noe code templates kan hjelpe deg med. Hvis du vil kopiere noen av templatene fra eksemplene finner du dem og noen til her.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Øyvind Norstein Øvregård
Finn-Robert Kristensen

Her er tre ting du kan gjøre:

Splitt opp på domene

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

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

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

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

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

Splitt opp på operasjon

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

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

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

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

Splitt opp på roller

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

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

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

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

Konklusjon

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

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

Hvilke teknikker bruker du på å bruker historiene dine?

I rollene våre i arbeidslivet søker vi alltid etter kreative og smarte måter å løse utfordringer på. Kreativitet kan dog være så mangt. Definisjoner varierer fra person til person og uttalelse til uttalelse. Hvordan defineres en kreativ person? Er man født kreativ? Kan man lære kreativitet? Alle er spørsmål det er vanskelig å gi et fullgodt svar på. Gjennom denne samlingen lot vi seks inspirerende foredrag fra TED.com diskutere emnet for oss. Noe som igjen gav grobunn for videre diskusjon utover kvelden.

For de som ikke hadde mulighet til å bli med denne gang såg vi følgende videoer:

• Elizabeth Gilbert on nurturing creativity
• Matt Ridley: When ideas have sex
• Sir Ken Robinson says school kills creativity
• Cameron Herold: Let’s raise kids to be entrepreneurs
• Adora Svitak: What adults can learn from kids
• Mick Ebeling: The invention that unlocked a locked-in artist

Takk til alle som ble med for nok en hyggelig aften med #TEDatSteria!

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

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

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

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

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

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

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

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

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

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

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

Nå skal det selvsagt sies at man helst bør følge de maler og bruke de rammeverk som arkitekten eller teamet sammen har tenkt at prosjektet skal bruke.  Sånn sett finnes det regler for hva som er rett og galt.  Men når det finnes slike maler og rammeverk, da stiller vi oss ikke dette spørsmålet. Det er når vi beveger oss utenfor de etablerte malene at spørsmålet gjerne dukker opp: Er dette riktig? Og det er litt trist når det skjer. For det er tegn på at vi ikke stoler på oss selv til å kunne komme med gode nok løsninger. Og det synes jeg vi skal gjøre. Det har vi all grunn til å gjøre, flinke som vi er

Vi bør absolutt fortsette med å stille spørsmål om hvorvidt koden vår kan forbedres. Men spørsmålet bør heller være “Hva synes du?” Vi bør fortsette med å involvere flest mulig. Men det bør gjøres som en diskusjon blant proffesjonelle utviklere der alle har gode poenger å komme med, og ingen sitter med fasiten. Det er da det er morro å jobbe som et team.

Programmering burde ikke bare oppleves som å fargelegge inni ferdig-opptegnede figurer. Det burde være litt frihånds-arbeide også. Det er når du føler at du er med på å skape løsningen at det er gøy å programmere. Og det er når man har det gøy at man jobber best og utvikler seg mest.

Men de ferske øynene kan føre til problemer…

Verdien av ferske øyne

Det er lett å se seg blind på egen kode. Når man skriver den har man det veldig klart for seg hva det er en prøver å utrette. Man tar sin egen forståelse av problemet for gitt og leser koden utifra denne egne forståelsen. Men ikke alle ser problemet i samme lys som en selv. Resultatet er ofte totalt uforståelig kode for andre.  Derfor er det kjempeviktig at andre også leser koden og flagger eventuelle uklarheter jevnlig. Det er tross alt vanskelig for en selv å vite hva det er en har tatt for gitt, ettersom man… har tatt det for gitt.

Faren ved ferske øyne

Det er likevel ET problem med ferske kritiske øyne. Spesielt hvis de får jobbe med koden helt uten tilgang til de opprinnelige forfatterne. På seg selv kjenner en andre, og jeg vet med meg selv at jeg fort tenker “Å herregud, hva er det her for noe dritt?!?!!” når jeg ser på andre folk sin kode. Spesielt hvis de ikke er der for å forsvare seg. “Dette kunne jeg gjort 1000 ganger bedre selv”. “Hvorfor har de gjort det SÅNN, når det er så utrolig mye bedre å gjøre det sånn.” Også setter man igang og skriver det hele selv fra scratch. Man bare MÅ! Det klør i fingrene. Dette fører da typisk til at de opprinnelige forfatterne reagerer med tilsvarende avsky mot min “forbedring”. Etter 10 år som programmerer har jeg sett andre gjøre dette mot hverandre gang på gang, jeg har gjort det selv altfor ofte og jeg har fått min egen kode skjelt ut og omskrevet (av meg selv til og med) Denne prosessen kan fort kaste bort mye tid og skape et dårlig arbeidsmiljø der ingen stoler på hverandre og man nesten ikke får lyst til å sjekke inn kode fordi man vet at folk kommer til å slenge dritt. I åpent landskap der man hører høyt og tydelig hvordan folk beklager seg over dårlig kode blir dette enda verre.  Selv om det ikke er ens egen kode det blir klaget over.  Det at folk akker og ojer seg over ting de ikke liker skaper en negativ atmosfære.  Jeg har selv lidd i slike miljøer. Og det plager meg at jeg sikkert har vært skyld i tilsvarende situasjoner på arbeidsplassen. Det er ikke konstruktivt. Jeg akter å forbedre meg og håper andre følger etter.

Pust, tell til 10 og involver de som skrev koden.

Det er som sagt viktig å få flagget kode som bør forbedres. Praktisk talt all kode kan forbedres. Kode som ikke er tydelig nok, kode som er for komplisert, kode som ikke er bra koblet sammen. Men det kan gjøres på bedre måter enn å himle med øynene, stønne, banne og sverte høylytt og så skrive om alt på nytt uten å involvere forfatterne. Jo lengre du sitter og “fikser” andres kode, jo mer irritert blir du på dem, og jo mindre vil du stole på deres evner i fremtiden.  Dette er ikke bra for team-spirit’en.  Snakk heller med personen som skrev koden og spør hva bakgrunnen for løsningen de har valgt er. Vær åpen for at du kan få et veldig godt svar. Kanskje løsningen er full omskrivning, og kanskje koden fortjener en høylytt OMG WTF, men løsningen kan også bare være bedre navngivning av metoder eller andre enkle refaktorerings-tiltak, eller kanskje du har totalt misforstått, og koden er så god den kan være.  Kanskje forfatterene er helt enig i at koden bør skrives om og kanskje de har gode ideer til hvordan dette kan gjøres.  Hvis vi jobber og snakker sammen, også der vi er uenige, får vi et mye bedre samarbeid og et mye bedre arbeidsmiljø.

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

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

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

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

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

Jeg brukte følgende libraries og verktøy:

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

Dag to begynner de på badet,  men mye tid går bort fordi en nybegynner klarte å bruke dobbelt så mange spiker som man trenger da han satte opp nye veggplater. Som proffesjonelle arbeidere kunne de ikke stå for slikt, så de rev ned alle platene og satte opp nye med “riktig” antall spiker.  Er du som kunde fornøyd med slik bruk av tid og ressurser?

Når de endelig nærmer seg slutten, får den ene arbeideren en dødskul ny flis-kutter. Den kutter fliser mye bedre og mer nøyaktig enn den de brukte da de satte opp flisene, så da tar de ned igjen alle flisene og setter opp nye.  Er du fornøyd?

Jeg bare spør, jeg. Rent hypotetisk, selvsagt.  For det er vel ingen som kjenner seg igjen i denne typen praksis?

Torsdag 17. februar deltok jeg i en TMMI workshop på et hotell i landet som holder rekorden i verden på å være uten regjering: Belgia. Vi var ikke så mange, så jeg fikk god kontakt med foredragsholderen. Dette til tross for at han hadde en infeksjon i øret og hørte seg selv mens han pratet, og jeg for min egen del hørte veldig lite på det ene øret etter en heftig flytur dagen før.

Foredragsholderen, Brian Wells, er en hyggelig engelsk TMMi-rådgiver som bor i Lille i Frankrike og jobber for Experimentus. Han har 25 års erfaring innenfor testbransjen og han har blant annet vært ansatt for hennes majestet Elizabeth, Queen of England. Likevel tror jeg ikke at han vil definere seg selv som en testhelt.

Experimentus har utviklet en metode som følger TMMis sin referansemodell og fått den godkjent. Det vil si at Brian Wells kan hjelpe organisasjoner med å vurdere hvor gode de er på test i følge TMMi, og gi dem råd om hvordan det er mulig å bli enda bedre.

Det finnes flere liknende modeller. Det som gjør denne litt spesiell er at den er tilgjengelig for offentligheten. Altså kan du utvikle din egen metode basert på den offentlige referansemodellen. Ved å gjøre dette kan dine resultater sammenliknes med andre som også bruker TMMi.

Flere egenskaper av TMMi modellen som jeg ville understrekke blant de mange som ble nevnt er følgende:

• Smidighet: Modellen støtter alle utviklingsmetoder.
• Internasjonal standard: Det finnes to bedrifter som leverer testtjenester og er TMMi-sertifisert på nivå 3. Det ene i Sør-Korea og det andre i Spania. Nivå 3 betyr at disse er i stand til å styre testaktiviteter, men også at disse aktivitetene er tydelige definert og gjenbrukes.
• Risiko: TMMi er veldig tydelig på at test er en aktivitet som styres av risikoanalyse.

Du kan prøve deg men en gratis gransking fra Experimentus:
http://www.experimentus.com/services-intelligentProcessImprovementiPI.html

Resultatene som er samlet hittil sier at ca. 72,5% av bransjen ligger på nivå 1 mens resten ligger på nivå 2.

Det er bare å gratulere prosjektet du jobber i dersom du får et bra resultat.  Fikk dere ikke det, må prosjektet passe ekstra godt på at deres testhelter er tilgjengelige når det gjelder. I hvert fall frem til test organisasjonen er moden nok.

Til slutt, et gratis råd fra Brian: Pass på å vite hvor organisasjonen din ligger i forhold til testaktiviteter før du prøver å gjøre den bedre, uansett hvilken modell du velger!

Denne samlingen satte vi et samlet tema for foredragene. Det som går igjen i alle videoene er kunnskap. De drøfter både hvordan få tak i informasjon, men like mye hvordan bruke den. Sistnevnte omhandler i stor grad også hvordan visualisere den og hvorfor det er et kraftig virkemiddel.

Fredag 4. februar viste vi følgende videoer:

• David McCandless: The beauty of data visualization
  Som åpning viste vi et foredrag av David McCandless, en journalist med sansen for statistikk som har fått øye på illustrasjon. Foredraget viser hvor fint informasjon kan illustreres og ikke minst hvor nyttig det kan være.
• Nicholas Christakis: How social networks predict epidemics
  I dette foredraget bruker Nicholas Christakis visualisering av sosiale nettverk til å predikere epidemier. Dette kan brukes til både se sykdom som sprer seg, lansering av et nytt produkt i markedet og mye mer.
• Tim Berners-Lee: The year open data went worldwide
  Tim Berners-Lee utviklet World Wide Web som et deltidsprosjekt for omtrent 20 år siden. Den tid skjønte ikke folk hva en skulle bruke det til. Nå etterspør han rådata om alt. Hva skal vi med det? Han viser veldig klare eksempler om hvordan bruke kombinert rådata.
• Hans Rosling: Let my dataset change your mindset
  Innen visualisering av informasjon er Hans Rosling et kjent navn. Hans entusiasme på senen ilag med  funnene han gjør og historien han forteller gjør alle hans foredrag verd minuttene og mer til. Rosling skal blant annet holde et foredrag under ISFIT i Trondheim 13. februar.
• Malcolm Gladwell on spaghetti sauce
  Verden gikk lenge uten å tilfredsstille sitt spagettisaus-ønske, uten at noen visste om det. Ved å stille de rette spørsmålene, og innse at for noen spørsmål finnes det ikke ét rett svar, fikk verden spagettisausen de faktisk likte best.

Var temaet interessant og ble samlingen bedre når vi holdt oss til et tema? Vi tar gjerne imot tips til både tema og videoer for neste samling!

“Obvious to you. Amazing to others.”

Du har garantert noe nyttig å dele. De fleste av oss er spesialiserte i ulike fagområder og ferdigheter. Ting som virker trivielle eller åpenbare for deg kan være kjempenyttig for andre. Så tenk deg om: sitter du på noe som virker “for åpenbart” til å dele med andre?

Ide-skuffen

Det er vanskelig å både finne en ide og skrive ferdig en god blogpost på en og samme kveld. Det er derfor lurt å samle og bearbeide ideer over tid.

Kjøp en notatblokk. Ta den med deg overalt. Hver gang du får en ide eller innsikt som muligens flere har nytte av, så skriver du den ned, kanskje med et par setninger. Snart har du en haug ideer og tanker som du kan skrive om.

Slik gjør jeg det: på laptopen min ligger en mappe som jeg kaller “ide-skuffen”. Til enhver tid ligger det 10-20 filer der med ulike ideer. Jeg skriver litt i dem når jeg kommer på nye poenger. Når en tekstene har nok kjøtt på beina så lager jeg bare en renskrevet blogpost av den.

Lang eller kort tekst?

En blogpost er ikke en skolestil. Det er ingen formelle krav om lengde eller struktur, så ikke stress over det: bare få ut stoffet ditt på en form som noenlunde lesbar. Finn en stil som er komfortabel for deg.

Her er to vidt forskjellige eksempler: Seth Godin og Steve Yegge. De har svært ulik form: Godin skriver noe hver eneste dag, ofte bare en paragraf eller to. Yegge derimot publiserer sjelden nye artikler, til gjengjeld skriver han da laaange tekster.

Still krav til deg selv

Det er lettere å få ting gjort når man har milepæler. Hvis man bare “venter på inspirasjonen” så koker det fort vekk i kålen. Jeg synes det er enklere å produsere ting når jeg har faste frister; jeg forsøker å ferdigstille en tekst hver kalender-måned (til enten sterkblanding.no eller min personlige blogg).

Skriveteknikk

De fleste av oss kan bli flinkere i grunnleggende skriveteknikk. Noen enkle grep gjør ikke bare blogging, men alt du skriver mer lesbart. Eksempler:

• Det er lettere å lese tekst brutt opp i paragrafer – unngå “wall of text”.
• Skriv aktivt og stramt. “Jeg grep pennen” er mer lesbart enn “pennen ble etterhvert hurtig grepet av meg”.
• Bruk enkelt, effektivt språk. “Utføre” er mer lesbart enn “operasjonalisere”.

En bok jeg liker godt er “The Elements of Style” av Strunk & White. Den er snart hundre år gammel men inneholder eviggrønne råd om skriveteknikk. Og den er selvfølgelig lettlest!

Tenk om noen er uenige med meg?

Hvis du er så heldig å få kommentarer der folk er uenige med deg så er det et tegn på at du gjør noe riktig: da skriver du iallfall engasjerende! Forsøk å få folk til å tenke “Ja!” eller “Nei!”… ikke et svakt “Tja”.

Nå, hva venter du på? Skriv!

Et godt foredrag starter med at du snakker om noe du kan. Og du kan mer enn du tror. Det er som regel sånn at de tingene du kan selv, føles som selvfølgeligheter. Men de erfaringene du har og de opplevelsene du har, de er unike for deg. Kanskje det er mange som har interessert seg for de sammen tingene som du har, men det er lite sannsynlig at de har samme perspektiv på tingene. Du bringer noe unikt til bordet. Velg et tema du har erfaring med, og du har tatt første skrittet til et fascinerende foredrag.

Når du skal bestemme deg for nøyaktig hva du vil snakke om, hjelper det å tenke på hvordan du vil påvirke ditt publikum. Publikumet ditt kan noe når de kommer til foredraget ditt. Ta utgangspunkt i at de vil noe med det de kan. Hvilket problem eller behov har de når de kommer inn i salen? Et vellykket foredrag kanaliserer denne viljen til handling: Hva vil du at de skal gjøre når de har hørt foredraget ditt? Skriv ned den (for deg) perfekte tilhørers kunnskap, vilje og handling etter at han eller hun har hørt foredraget. Dersom du kan beskrive en transformasjon som engasjerer deg, har du tatt skritt nummer to til et fascinerende foredrag.

For å oppnå noe, kreves arbeid. Når du holder et foredrag er det viktigste arbeidet du gjør å trene på å snakke. Bruk under 30 minutter på å strukturere tankene dine før du prøver å holde foredraget første gangen. Hold det for deg selv, men snakk høyt. Tren mange ganger. Tren foran andre om du kan. Tren minst tre ganger på foredraget før du lager en eneste slide. Tren mange ganger på foredraget ditt, og du vil komme i mål med et fascinerende foredrag.

Dersom du får med deg hodet (kunnskapen), hjertet (viljen) og kroppen (treningen), så er du garantert å holde et bra foredrag.

Øvelsene kan tjene som inspirasjon til dine egne retrospektiver og workshops.

Jeg brukte tre workshop-øvelser under hele workshopen:

• “Tenke og svare”: Et retrospektiv kan være en sjelden anledning til å bare sitte og tenke uavbrutt. I “tenke og svare” øvelser får deltagerne to minutter i stillhet til å tenke på svaret til et personlig spørsmål. Etter to minutter får alle fortelle svaret sitt, mens resten av gruppen og moderatoren lytter.
• “Tre svar på tre spørsmål i grupper på tre”: Deltagerne blir delt i grupper på tre som alle skal finne tre svar på hver av tre spørsmål. Etter ti minutter avgir gruppene ett svar hver. Dersom spørsmålene krever handling, kan deltagerne i plenum stemme fram hvilke svar de ønsker å handle på grunnlag av
• “Snakker og lytte”: Det er overraskende sjelden vi blir lyttet uavbrutt i ett minutt, eller lytter oppmerksomt til en annen i et minutt. I “snakke og lytte” øvelsen får deltagerne et personlig viktig spørsmål og blir delt i grupper på to og to. I hver gruppe skal én person snakke og den andre lytte i ett minutt. Etter ett minutt bytter parene roller.

På Smidig 2010 kjørte jeg workshopen som et retrospektiv av den første dagen på konferansen. Øvelsens form var delvis inspirert av “Agile Retrospektives” av Diana Larsen og Esther Derby. “Agile Retrospekives” anbefaler en fem-stegs prosess som ledet hovedstrukturen for workshopen:

1. Set the stage: “Tenke og svare” øvelse med på spørsmålet “Hva har vært høydepunkter så langt”
2. Gather data: “3×3 spørsmål” øvelsen der to av spørsmålene var for å samle data. (“hva har overrasket meg” og “hva har jeg lært”)
3. Generate insights: “Lytte og snakke” øvelsen med spørsmålet “hva vil gjøre meg lykkeligere”. Av praktiske grunner gjorde jeg den etter det siste spørsmålet fra “3×3 spørsmål”.
4. Decide what to do: Det tredje spørsmålet fra “3×3 spørsmål” var “hva vil du lære mer om”. Etter at ti grupper hadde kommet opp med ett svar hver, stemte vi i plenum på de mest interessante temaene.
5. Close the retrospektive: Å tenke og svare på spørsmålet “hva håper du å oppleve” var øvelsen som avsluttet retrospektivet.

For å få en mest mulig konstruktiv dialog, forsøkte jeg å strukturere spørsmålene etter inspirasjon fra “Appreciative Inquiry”. Ola Ellnestams blogpost om Appreciative Inquiry Retrospectives var en viktig kilde til inspirasjon.

Hvilke spørsmål kan du tenkte deg å stille til “tenke og svare”, “3×3 spørsmål” og “snakke og lytte” øvelser? Hvilke spørsmål kan hjelpe gruppen å generer innsikter, samles om et mål og gå ut av retrospektivet fulle av ideer og håp for fremtiden?

Jeg har vært så heldig å være på et prosjekt med en produkteier som har sørget for at vår innsats har blitt brukt til å effektivt skape verdi for brukerne av systemet. Jeg vil trekke fram mine observasjoner om hvordan produkteieren på dette prosjektet brukte produktkøen, hvordan han skapte dialog med brukerne og hvordan han kommuniserte effektivt med utviklerne.

Produktkøen

Produktkøen er produkteiers fremste verktøy for å styre prosjektet dit han ønsker. Det viktigste med produktkøen er derfor at den er representert i et verktøy produkteieren er komfortabel med å bruke. Vår produkteier brukte Excel, noe som fungerte godt for dette prosjektet. Hver brukerhistorie var en rad i et regneark. Når vi skulle endre prioritet, kunne vi dra og slippe en brukerhistorie til riktig sted. (Dette er et lurt knep å lære i Excel).

Etter hver iterasjon gikk jeg som Scrum master og produkteieren gjennom alt som var levert i iterasjonen. Vi markerte i produktkøen hva som var levert og hva som ikke var levert. I iterasjon 4, 5 og 6 skjedde noe merkelig. Iterasjon 4 hadde vi planlagt 7 brukerhistorie-poeng, men leverte 4. I iterasjon 5 hadde vi planlagt 7 og leverte 7. I iterasjon 6 hadde vi planlagt 7 og leverte 10. Det som skjedde var et en stor brukerhistorie var nesten ferdig på slutten av iterasjon 4. En ny stor brukerhistorie var nesten ferdig på slutten av iterasjon 5, og denne brukerhistorien fikk vi endelig levert i iterasjon 6. Produkteier insisterte på at en brukerhistorie var enten ikke ferdig (0%) eller helt ferdig (100%). Dette gjorde at det aldri var noen skjønnsvurdering om hva vi hadde levert.

I prosjektet vårt skulle vi erstatte et eksisterende system. Produkteieren var veldig bevisst på å prioritere et sammenhengende sett med brukerhistorier som gjorde at brukerne kunne benytte de leveransene vi ble ferdig med i løpet av prosjektet. Det var to viktige vurderinger som produkteier tok: For det første må brukerne kunne utføre en arbeidsoppgave i den nye systemet, og ikke måtte hoppe mellom det nye og det gamle. For det andre må leveransene inneholde funksjonalitet som er interessant for brukerne.

Personer og samspill

Men produktkøen er den minst viktige delen av produkteiers jobb. Det smidige manifestet sier det selv: “Vi verdsetter personer og samspill over prosesser og verktøy.” Det er to viktige grupper som produkteieren må forholde seg til: Brukerne og utviklerne.

Involvere brukere

Før prosjektet startet, hadde produkteieren involvert brukerne i prosjektet. Mange brukere var blitt spurt om hva de mente var viktig med det nye systemet og noen brukere var valgt ut til en fokusgruppe. De to mest involverte brukerne deltok hele veien i prosjektet. Produkteieren identifiserte to brukere som de andre brukerne respekterte faglig, som forsto dagens system godt, som hadde meninger om hvordan ting burde være, og som ikke var redd for å si disse meningene.

Så snart vi hadde et produkt som kunne vises fram, satt vi dette i drift i demoversjon som brukerne kunne teste ut. Det viste seg å være vanskelig å få brukerne til å prioritere å teste det nye systemet. Det hjalp litt når produkteieren ga dem en oppgave de skulle utføre med det nye systemet (hjemmelekse). Det hjalp veldig når brukerne kunne bruke det nye systemet mot produksjonsdata som en del av jobbe sin.

Ekspertbrukerne deltok på alle demoer. Ettersom en av de bodde i Rogaland og en i Hedmark, var det vanskelig for dem å reise til Oslo for hver eneste to-ukers iterasjon. De første iterasjonene var de alltid til stede, men etter dette kjørte vi kun demo annen hver iterasjon. Etter et halvt år i prosjektet forsøkte vi også å kjøre noen demoer med screen sharing (go-to-meeting, tror jeg) og telefonkonferanse. Det fungerte ok, men vi fikk mye nyttigere feedback når vi møttes ansikt til ansikt. Ekspertbrukerne hjalp oss å bli flinkere og validerte arbeidet vårt når et var bra.

Kommuniserer med programmere

For å ha framdrift, var prosjektet avhengig av at produkteier og utviklere møtes hver dag. Produkteier deltok på standup-møtene hver morgen. Etter standup-møtene hadde han satt av opp til en time der en utvikler kan vise fram ny funksjonalitet og få tilbakemeldinger, der produkteier kan gi tilbakemeldinger til en utvikler på funksjonalitet han testet i går og der produkteier kan forklare detaljene rundt nye brukerhistorier.

Når produkteieren forklarte brukerhistorier, var han flink til å være konkret. Dette er alfa og omega når en produkteier snakker med utviklere. Forskjellen på å vise fram en skjermbildeskisse og å forsøke å beskrive et abstrakt behov er gigantisk. Forskjellen på å fortelle et eksempel og å forklare en abstrakt arbeidsprosess er enorm. Ved å bruke eksempler til å forklare brukerhistorier var produkteiers forklaringer gode for utviklerne.

Til slutt var produkteieren vår rask til å bestemme seg. Dersom det var et uklart valg, fikk vi ofte en avgjørelse der og da. Når produkteier måtte sjekke med andre, tok det en eller to dager før han kunne gi oss en beslutning. Noen ganger fant han senere ut at han måtte ombestemme seg. Da utførte vi ganske enkelt den endelig løsningen i en senere iterasjon. Det er mye mer effektivt å utvikle noe som er en rimelig hypotese, få tilbakemelding og så utvikle det riktige, enn det er å vente på en beslutning.

For å lykkes som produkteier, må du kunne bruke produktkøen effektivt, du må involvere brukerne dine gjennom hele prosjektet og du må kommunisere med utviklerne hver dag. Da vil du ha et vellykket Scrum-prosjekt!

Et scriptspråk kan være et kraftig verktøy for å konfigurere java-applikasjonen din. Det tillater endringer på en kjørende applikasjon. Det gir deg frihet til å endre på kjørende javakode som du velger å eksponere. Det er kjent og kjær teknologi og derfor enklere å få tak i ansatte med riktig kompetanse enn om du velger mindre kjente teknologier. Og kanskje det viktigst av alt, et argument som burde veie tyngre enn det ofte gjør i avgjørelser; det er enkelt.

Min spontane reaksjon på forslaget var “er du gal!”. Målet var å kunne endre regler for automatisk saksbehandling mens systemet kjørte. Ideen var å eksponere disse reglene via jRuby. Min kollega, Trond Pedersen, som hadde kommet med forslaget lo litt og viftet det vekk som et forslag fremmet bare for å vise at det er lov å tenke kreativt. Jeg lot ideen ligge resten av dagen. Først da jeg kom hjem lot jeg den få en rettferdig sjanse. Den var egentlig ganske tiltalende. Dersom vi valgte å gjøre konfigurasjon via filer som inneholdt tekst og verdier ville vi kunne slå av og på regler og sende inn verdier til reglene. Men hva om vi eksponerte et java-API via et scriptspråk istedet? Det åpner for å endre på hva man måtte ønske å eksponere. “Tør vi det” tenkte jeg.

Jeg bestemte meg for å se nærmere på ideen. Før jeg forelår noe sånt vil jeg gjerne se hvordan vi kan løse det i praksis tenkte jeg. 30 minutter med litt leiting på verdensveven og litt lek og moro i eclipse hadde jeg et kjørende eksempel med en java-applikasjon som eksekverte jruby-kode. Et javaobjekt ble sendt som parameter til jrubyscriptet. Scriptet kalte metoder på javaobjektet og returnerte en verdi tilbake til java-applikasjonen. Det finnes masse eksempler om man leter litt på verdensveven men for at du skal slippe å lete så viser jeg mitt her.

Først litt javakode:

import java.io.File;
import java.io.FileReader;
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;

public class RunRuby {

public static void main(String[] args) throws Exception {

  ScriptEngineManager factory = new ScriptEngineManager();
  // Create a JRuby engine.
  ScriptEngine engine = factory.getEngineByName("ruby");

  // Evaluate JRuby code.
  engine.eval(new FileReader(new File("src/rubyscript.rb")));
  engine.put("object", new Object());

  // Run the ruby-method reverseToString
  String value = (String) engine.eval("reverseToString($object)");

  //java.lang.Object@something is printed backwards
  System.out.println(value);
  }
}

Javakoden tolker en scriptfil, rubyscript.rb, og kjører metoden evaluate. Se eksempelkoden til rubyscript.rb:

require 'java'
def reverseToString(javaObject)

  # returns the reverse of the objects tostring method
  return javaObject.toString().reverse()

end

Når passer det å bruke dette vektøyet til konfigurasjon? Når du vil gjøre endringer uten å måtte kompilere en ny applikasjon og starte den opp i produksjonsmiljøet ditt. Er det enkelt å forutse disse endringene kan du trolig like gjerne gjøre det i en tekstfil med forhåndsdefinerte verdier som leses inn av applikasjonen din. Når du derimot synes det er vanskelig å forutse hvilke endringer du har lyst til å gjøre har du nå et kraftig verktøy. Bruk et scriptspråk. Velg gjerne ditt eget favorittscriptspråk. Om det er jRuby, JavaScript, Scala, Clojure eller et annet scriptspråk er opp til deg. Finn din favoritt som er kjørbar på JVM og du er igang på 1-2-3.

Systemutviklere er både heldige og uheldige. Vi kan tilegne oss kunnskap og ferdigheter helt på eget initiativ, men vi tvinges også til å gjøre det for å holde oss relevante, ettersom teknologi endrer seg raskt.

Selv synes jeg at det er topp å plukke opp nye ting – her er noen metoder for å lære…

Bredde eller dybde?

Tenk på kunnskap som personøkonomi. Ikke invester alt i en aksje (“Jeg kan bare Java!”). Spre eggene dine over flere kurver. For all del: legg ned tid i mainstream-teknologi som er populær idag. C# og Java f.eks er lavrisiko med grei avkastning. Men se også på nisje-teknologi (la oss si F# eller Scala, for eksempel) Disse er mer høyrisiko fordi det absolutt ikke er sikkert de blir populære i fremtiden. Smale temaer gir til gjengjeld langt høyere avkastning hvis de slår an: du får et fortrinn fordi du var tidlig ute.

Balanse mellom generelle og spesialiserte emner. Brede, eviggrønne felt (f.eks OO-design, regular expressions, statistikk) hjelper deg i mange år, uavhengig av domener og platformer. Men ikke overse domenekunnskap og platformspesifikke verktøy (Oracle og Microsoft) som gjør deg mer ettertraktet i prosjekter her og nå.

Kultiver personlige styrker. Hvis du bare kan “litt om alt” så er det vanskelig å utmerke seg. Finn en eller to ting som er dine hovedpillarer, som du stadig forbedrer og behersker bedre enn andre. Hva gjør at du skiller deg ut? Hva er ditt “Unique Selling Point”?

Studieteknikk-kungfu

Du har et enormt arsenal av studieteknikker. Min erfaring: jeg lærer meg ting langt mer effektivt nå enn da jeg var i skoleverket eller på universitetet. Dels fordi jeg har blitt flinkere til å lære, men mest fordi vi har fått flere måter å tilegne oss kunnskap. Her er en liten godtepose av muligheter:

• Universiteter verden over legger ut åpen “courseware”: videoforelesninger, notater, pensum, oppgaver, fritt tilgjengelig på nett.
• Screencasts er en fin blanding av foredrag og praktiske demonstrasjoner. Noen av dem må du betale for. De er derfor ofte optimalisert for å levere lærdom og verdi, mer enn en umotivert foreleser på Blindern noengang blir…
• “So You’d Like To…”-guidene hos Amazon.com er i noen tilfeller knallbra utvalg av faglitteratur og fungerer bra som utgangspunkt for selvstudium.
• Online nyhetsblogger og foredrag fra konferanser gjør deg oppdatert på tilstanden i fagfeltet ditt.
• Podcasts og lydbøker gjør iPoden din til en forelesningssal – kanskje mens du tar oppvasken?
• Møt andre engasjerte i meetups, brukergrupper, code camps og online studiegrupper. Få feedback fra likesinnede, ikke gjem deg bort!
• Open source lar deg kikke bak kulissene og se hvordan andre utviklere jobber og tenker.
• Mindmapping er en sterk måte å ta gode, raske notater mens du studerer.

Og dette var bare en tilfeldig utvalg. Med andre ord: dersom du begrenser deg til å kun lese en papirbok i ny og ne så handicapper du deg selv. Du har mange muligheter!

Absorber som en svamp. Hvis jeg har en ekstrem “læredag” så hører jeg på en podcast når jeg går til stasjonen på morran, leser litt i en relatert bok mens jeg sitter på toget, plugger inn iPoden igjen når jeg bytter over til tbanen til jobben, samme opplegg på veien hjem på ettermiddagen, og setter meg ned og koder en prototyp etter at ungene har lagt seg. Teknikkene nevnt i forrige avsnitt gjør det stadig enklere å presse inn læring flere steder i hverdagen enn man kunne før.

Jevn progresjon. Store skippertak kan fungere, men det er i lengden bedre å lære litt hver dag istedet. Når man er student så fungerer sånne “overdoser” til en viss grad, men det blir vanskeligere når du har jobb og familie. Tenk bærekraftig tempo…

Bruk det du lærer

Jobb med relevante prosjekter i arbeidstida. Dette er idealsituasjonen, men lar seg ikke alltid gjøre. Prosjekter krever vanligvis at vi leverer det vi allerede behersker, ikke det vi ønsker å lære mer om. Derfor kan det bli nødvendig å…

Lage ting på fritida. Bruk det du har lært til å gjøre sideprosjekter på egenhånd. Ambisjon og omfang trenger ikke være all verden, bare du lager noe konkret og nyttig. Du kan lage et verktøy eller en tjeneste som bare du selv trenger, eller slippe det som open source eller en kommersiell tjeneste for hele verden. Poenget er at du anvender kunnskapen til noe konstruktivt. Det kan være slitsomt å bruke fritida til dette – til gjengjeld eier du selv det du lager. Og du får en “portfolio” å vise til.

Lær det bort til andre! Når du formidler til andre (f.eks via kurs, blogging, foredrag) så tvinges du selv til å få bedre grep på stoffet ditt. Du trenger ikke være guru for å lære bort ting – det holder at du har noenlunde grep om temaet og evner å formidle det godt.

Robert “Uncle Bob” Martin sa på et av foredragene sine at en profesjonell utvikler må bruke tjue timer hver uke på å forbedre seg som håndtverker. Dette er kanskje ekstremt – men hvor mye gjør du selv? Og hvordan lærer du nye ting? Del gjerne av egen erfaring i kommentarene under!

Bedre kommunikasjon

• Inkluder produkteier på morgenmøtene: Daglig kommunikasjon mellom kunde og leverandør har en dokumentert enorm effekt på hvor vellykket et prosjekt blir. Teamets fokus blir mye bedre dersom det er noen på de daglige standup møtene som er interessert i å prøve ut det som har blitt laget i går, som er interessert i å komme med innspill på det som lages i dag og som har myndighet til svare på avklaringer angående dagens oppgaver.
• Programmér sammen: Utviklere på prosjekter innehar enorm kunnskap, både om de delene av systemet man lager og om programmering generelt. Når man programmerer i par og roterer hvem som jobber sammen hyppig, blir denne kunnskapen spredt til alle. Spe også gjerne på med seanser der hele teamet går gjennom deler av koden på storskjerm.
• Bruk en Scrum-tavle: For å hjelpe alle å huske på hva som er målet med sprinten, er det lurt om teamet holder standup møtene rundt en tavle med lapper for alle aktiviteter teamet har planlagt i iterasjonen. Lappene henger i kolonner “venter”, “under arbeid” og “ferdig”. Hver lapp bør ha et så lite omfang at teamet flytter flere lapper til “ferdig” hver dag.

Bedre kvalitet

• Verifiser krav med funksjonelle tester: Når teamet skal jobbe med en oppgave i en iterasjon, er det viktig at alle har konkret forståelse av oppgaven. Produkteier bør beskrive eksempler for å gjøre oppgavene konkrete. Om mulig, bør produkteier uttrykke eksemplene i et verktøy for automatisert funksjonell testing (for eksempel FitNesse eller Cucumber). Teamet kan da kjøre testene og automatisk sjekke at de oppfyller produkteiers forventning
• Skriv enhetstester før koden den tester: For å kunne utvikle funksjonalitet inkrementelt, må man kunne endre på kode som allerede har vært ferdigstilt, samtidig som man er (rimelig) sikker på at endringen ikke ødelegger noe som har virket før. De funksjonelle testene kan gi et sikkerhetsnett, men det tar typisk lang tid å kjøre dem og de gir ofte ikke en eksakt indikasjon av hva som er feil når noe ikke virker. Derfor bør teamet skrive raske tester som verifiser at klassene i systemet fungerer, gjerne før man skriver koden.
• Integrer endringer kontinuerlig og automatisk: Automatiske tester er kun verdifulle dersom de kjøres! Sett derfor opp en Continuous Integration server som sjekker ut og tester alle endringer hver gang en utvikler har sjekket inn en endring til kildekodekontroll. Om mulig bør dette systemet også automatisk installere den siste versjonen av programvaren til et egnet testmiljø, slik at produkteier alltid kan se hva som er siste versjon av systemet.

Bedre forretningsfokus

• Inkluder alle oppgaver i en prioritert produktkø: Mange team lurer på hvilke oppgaver som skal puttes på produktkøen. Dersom noe gir forretningsverdi og tar betydelig tid å utføre, bør produkteier inkludere oppgaven på produktkøen. Ikke-funksjonelle krav må som regel testes. Det tar tid å sette opp testene og rette opp eventuelle mangler. Ikke-funksjonelle krav skal på produktkøen. Brukerdokumentasjon må skrives og kvalitetsikres. Det tar tid å skrive god brukerdokumentasjon. Brukerdokumentasjon skal på produktkøen.
• Bli helt ferdig med funksjonalitet: Teamet får kun “poeng” for helt dønn ferdig utført arbeid. Etter en iterasjon bør alt som tilhører en oppgave være så ferdig at det er greit dersom man aldri mer bruker tid på koden. Koden, tester og dokumentasjon må være i en akseptabel tilstand. Det betyr ikke at koden er frosset. Dersom man for eksempel utfører en oppgave for å verifisere responstid, må teamet oppdatere eksisterende kode slik at den støtter tidsmålinger og at man korrigerer eventuelle ytelsesproblemer man oppdager. Dette arbeidet tilhører det å implementere responstidskravet – den originale funksjonen er ferdig.
• Ta med brukere på demo: Dersom du lager et system som interesserer dine (fremtidige) brukere, bør teamet ha noe spennende å vise dem på demo etter hver iterasjon. Bruk demo-møtet til å involvere brukerne. Sørg for at input fra brukerne blir tatt hensyn til, og at de får beskjed om innspill som har blitt implementert, slik at de fortsetter å interessere seg.

Gjort riktig kan et smidig prosjekt levere ferdig funksjonalitet for hver iterasjon. Men det krever fortløpende kommunikasjon, kvalitet og fokus på forretningsverdi. Dét er hvordan du lykkes med smidige prosjekter.

Jeg planlegger å publisere en Steria 3-minuttersguide basert på denne artikkelen. Innspill til forbedringer mottas med stor takk!

Hvordan havner man i slike situasjoner? Kan de unngås?

Er det arkitekten sin skyld?

Det er lett å skylde på arkitekten og kalle ham (eller henne) for en idiot og et stabeist, men er dette rettferdig? Både ja og nei. Stabeist er kanskje korrekt, men idiot er vedkomne neppe. Intelligens er evnen til å finne gode generiske modeller som kan brukes til å finne løsninger i en kaotisk hverdag. Idioter pugger tallene i boka og ser ikke sammenhenger. Intelligente mennesker lærer seg reglene for å regne seg frem til alle mulige tall – ikke bare de i boka. En god og intelligent arkitekt er en som kan finne enkle overordnede strategier som gjør applikasjonen som helhet ryddig og pen. Fra et kaos av brukerhistorier og kundekrav skal han eller hun finne enkle og elegante strategier som kan brukes til å løse alt. Hvis alle programmerere kunne gjøre akkurat som de ville for hver brukerhistorie, hadde koden endt opp i kaos. Alle hadde funnet opp sine egne hjul, og noen av dem hadde nok vært ganske kantete og skjeve. I vedlikeholdbarhetens navn om ikke annet er det klart at arkitekten ønsker seg felles løsninger og forutsigbare implementasjoner. Men finnes det alltid én løsning som passer overalt? «Gjør alt så enkelt som mulig, men ikke enklere» sa Einstein. IQ-tester måler evnen til å finne enklere løsninger, men de måler ikke nødvendigvis evnen til å se når nok er nok.

Maks antall personer = 150

Når utviklernes hoved-utfordring er å få løsningen til å passe inn i arkitekturen er det klart at noe har gått galt. Min teori er at disse situasjonene er et tegn på at prosjektet har blitt for stort. Akkurat som at store firmaer gjerne er mye tregere enn mindre firmaer, blir store prosjekter tregere enn små. Tregere både når det gjelder utførelse av eksisterende oppgaver, og enda mer når det gjelder innføring av nye prosesser. Antropologen Robin Dunbar har oppdaget at 150 mennesker det meste folk klarer å holde styr på. Det militære og flere firmaer har tatt dette med i betraktning og passer på at organisasjons-enheter aldri inneholder mer enn 150 mennesker. Selv om man ikke kjenner alle, så vet man hvem de er og hvor de jobber. Hvis man trenger noe gjort, kan man bare gå bort til den man vet man bør snakke med, og få det gjort der og da. Når organisasjonen vokser over 150 mennesker vet man ikke lenger hvem det er man må kontakte for å løse problemene sine. Man må da henvende seg til sjefen sin, eller en helpdesk på andre siden av kloden eller noe slikt, og håpe på at de igjen klarer å finne frem til den som kan hjelpe. Jo større og bedre organisert bedriften er, jo mindre effektiv blir kommunikasjonen. Når IT-support sitter i Jakarta, lønningskontoret er i Stavanger og markedsføringen foregår i Dubai, så blir det dårligere kommunikasjon enn om alle var i samme bygg. Mange mener at slik må det bare være når firmaet vokser, for man kan da ikke ha lønnskontor, IT-support og markedsføring i hvert eneste kontor når man har hundrevis av kontorer verden over. Jeg er ikke enig. I smidige prosjekter utvikler man ikke database-koden, business-logikken og GUI-koden hver for seg. Man utvikler brukerhistorier hver for seg. GUI, business-logikk og database-greier samtidig. Jeg tror noen store firmaer kunne lære mye her. Istedenfor å samle alle IT-avdelinger under ett tak, tror jeg det lønner seg å heller samle alle som har med samme produkt under ett tak. Design, produksjon, markedsføring, IT-support og alt som hører med til et produkt. Hver business-enhet bør være istand til å tjene penger. Slik organisering koster kanskje mer, men den vil også produsere og tjene mer.

Maks antall klasser i et prosjekt = ?

Mye av det samme skjer i store software-prosjekter. Når prosjektet vokser og vokser ender man fort med å gruppere koden etter «software tier» og ikke etter bruksområde. Man lager regler som at «slik snakker vi med databasen» og «slik skriver vi rapporter». Og reglene gjelder for alle uansett. Jeg tror man med fordel heller burde dele prosjektet inn i separate produkter. Produktene vil bestå av en samling av brukerhistoriene som passer sammen på et vis. Disse produktene trenger ikke ha samme regler for bruk av database eller noe som helst. Arkitekten og utviklerne står fritt til å finne løsninger som passer best for akkurat dette produktet. Jeg tror ikke denne typen tankegang kommer naturlig for folk med høy IQ. IQ driver folk til å se mønster og finne fellestrekk og dermed gruppere alt som likner. Her var det oppkobling mot database, der var det oppkobling mot database – da slår vi dem sammen! Her var det et lønnskontor, der var det et lønnskontor – da slår vi dem sammen! Det føles godt og opp til et visst nivå er det selvsagt det rette å gjøre. Men et sted går grensen. Hvor da? Når bør man begynne å tenke på splitting? I business-verden er 150 et tall å huske på. Har vi tilsvarende tall for software-utvikling? Hvor mange klasser kan et prosjekt ha? Er det antall klasser vi burde telle? Siden det er så fristende å finne fellestrekk og lage felles løsninger, tror jeg det hadde vært greit å ha noen konkrete tall og grenser å forholde seg til. Når man disse grensene kan man begynne å tenke seg om: Har prosjektet blitt for stort? Kan jeg dele det inn i mindre enheter? Kanskje svarene er nei, men det er viktig å stille seg spørsmålene like vel.

-

Har du hørt om nettskyen før? Kanskje i det minste du har hørt om Cloud Computing? Det er få innenfor IT-industrien som ikke har hørt om nettskyen til nå, det er liten tvil at nettskyen blir hypet, men det betyr selvsagt ikke slik at nettskyen i seg selv er en hype, selv om enkelte liker å lovprise litt for mye.

Petter Gottschalk er en av dem som varsler om å være litt nøktern til nettskyen, noe han har rett i. Vi er en bransje som er glad i alt nytt, ofte også med dramatiske konsekvenser, positive og negative. Tjenesteorientert-arkitektur (SOA) er en annen viktig utvikling som skjedde i vår bransje, en utvikling som har har brakt mye glede og motgang. Tjenesteorientert-arkitektur er komplisert, mye mer komplisert enn hva mange ble fortalt og overbevist om. Det er smart og strategisk å bygge løsninger basert på SOA, men det koster penger. Integrasjoner og interopabilitet med kunder og samarbeidspartnere er noe av det mest kompliserte vi gjør idag.

Fra et teknologisk ståpunkt er det veldig lett å komme igang med tjenesteorientert-arkitektur, vi har plattformer som gjør det mulig å lage tjenester fort og enkelt. Det vi undervurderte var kompleksiteten som oppstår når man begynner med integrasjoner og gjenbruk av tjenester. For mange undervurderte også behovet for planlegging av vedlikehold, versjonering, sanering og så mye annet som man må ha kontroll på når man bygger en infrastruktur på SOA. SOA har vist seg å være for komplisert og for dyrt for mange, gevinstene har ikke alltid vært der for å veie opp for investeringer som er gjort.

Hvorfor har man ikke klart å hente gevinstene fra SOA-satsninger?

Det er mye en organisasjon må gjøre for å omstille sine prosesser og systemer for å oppnå en velfungerende infrastruktur for SOA. Disse investeringer har hver enkelt vært nødt til å gjennomføre, hver for seg. Det sier seg selv at det fort blir kostbart, spesielt med tanke på at mange SOA-løsninger gjerne kun er for interne IT-systemer og integrasjoner med begrenset antall samarbeidspartnere. Desto større en organisasjon er, desto større verdi vil man kunne få ut av sine SOA-investeringer.

Nettskyen handler på flere måter om outsourcing av SOA…

Tjenesteorientering i nettskyen

Norge er et lite land tatt i betraktning hele verden, vi har et veldig begrenset marked av lokale kunder innenfor våre egne grenser. Dette er noe som alltid må være med i en vurdering om hvordan og når man skal ta i bruk både SOA og nettskyen. Dette er også noe av det som gjør nettskyen spesielt spennende for det norske markedet.

Fremfor at hver enkelt skal etablere sin egen tjenesteorienterte arkitektur, kan vi ved hjelp av nettskyen leie de delene av en infrastruktur og arkitektur vi har behov for. Det som er styrke i nettskyen er ikke bare muligheten til å skalere, men bredden av muligheter som finnes.

Konseptene i nettskyen

Begrepet nettskyen beskrives gjerne med tre underliggende konsepter: Software as-a Service, Platform as-a Service og Infrastructure as-a Service.

SaaS er programvare i nettskyen

- Det øverste nivået av nettskyen handler om å leie programvare, ferdige løsninger som ofte leveres rett i nettleseren. Kundebehandlingsløsninger (CRM), planleggingsverktøy, analyseverktøy og så utrolig mye annet finnes som man raskt og enkelt kan leie etter behov.

PaaS er kjøremiljø nettskyen

- Videre derfra har vi ulike plattformer hvor man kan bygge skreddersømsløsning og integrasjoner etter egne behov. Kan kjøre egne programmer og systemer i nettskyen, og samtidig utnytte godt av de infrastrukturtjenestene som eksisterer der ute for å dekke behov som autentifisering av brukere, sikker og kryptert kommunikasjon, tjenester-hubber (Internet Service Bus), globale caching løsninger, m.m..

IaaS er infrastruktur i nettskyen

- I nettskyen kan man leie de maskinressursene man har behov for, dette kan være database servere, brannmurer, webservere, m.m..

Dette er de mest etablerte prinsippene for nettskyen, men det er også flere andre prinsipper og beskrivelser og dette vil sannsynligvis utvikles i tiden fremover.

Spar på investeringer, kom fortere igang

Ett av de mest brukte budskapene om nettskyen er nemlig det jeg akkurat har forklart: Man slipper dyre investeringer i maskinvare, programvare og tjeneste for å komme igang. Man kan leie det man trenger, av maskinvare og programvare.

Styrken til nettskyen ligger nemlig i det at vi alle går sammen om å investere på infrastrukturen, for deretter å dele på ressursene. Har du noen gang hørt noen selge deg SOA og fortalt at dette er raskt og enkelt å komme igang med? Ble du fortalt at SOA var billig?

Teknologiene vi utviklet under SOA-hypen har vært instrumental for realisering a nettskyen slik den fremstilles idag. Nå har verden blitt moden og vi har fått en infrastruktur vi alle kan nyte godt av. På samme måte som vi alle i dag nyter godt av felles infrastruktur i den moderne samfunnet, som vann og strøm, kan vi nå nyte godt av datakraft og tjenester i nettskyen.

Fagruppe for Cloud Computing

I høst har Den Norske Dataforeningen startet en ny faggruppe for Cloud Computing, hvor Peter Flem fra Capgemini er leder og jeg er en av nestlederene. Ett av våre mål er å hjelpe norske bedrifter til å se mulighetene og verdiene av nettskyen, samt redusere noe av tåken som har oppstått med hypen. Vi arrangerer fagmøter gjevnlig og ønsker å invitere alle som ønsker å lære mer om nettskyen.

Neste møte er 20. oktober, hvor jeg skal fortelle om integrasjoner i nettskyen.

Steria og nettskyen

Hos Steria har vi gjennomført flere SOA-prosjekter med suksess og vi er allerede godt igang med satsning på nettskyen, både med infrastruktur og utvikling. SOA-investeringer hos våre kunder har gjort dem mer forberedt for nettskyen og forenkler fremtidige integrasjoner i nettskyen.

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

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

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

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

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

Imagine this “happy day situation” in your project:

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

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

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

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

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

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

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

So, get on with it! Good luck! 

P.S:

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

D.S.

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

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

Lykke til, Buglock!

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

Nesten daglig sitt-ned-møte

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

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

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

“Jeg vet det når jeg ser det”

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

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

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

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

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

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

Et eksempel: Å få deltagerne til å følge resonnementet ditt

Dette er et spørsmål jeg stilte til deltagerne på et scrum-kurs som jeg holdt flere ganger. Jeg lærte etter hvert hva som fikk forsamlingen til å svare:

1. “Skal teammedlemmene avgi status til Scrum master på morgenmøtet?” (svaret er “nei”, men sjansene for at noen føler seg dumme fordi de svarte feil er nesten 50%)
2. “Hvem skal teammedlemmene avgi status til under morgenmøtet?” (svaret er “hverandre”, men sjansene for at noen føler seg dumme fordi de svarer feil er godt over 50%)
3. “Hvorfor skal teammedlemmene ikke fortelle status bare til Scrum master på morgenmøtet?” (for åpent, folk vet ikke hvordan de skal angripe spørsmålet)
4. “Hvordan skal teammedlemmene fortelle status på morgenmøtet?” (fortsatt for åpent)
5. “Hva er feil dersom teammedlemmene gir status til Scrum masteren på morgenmøtet?” (nå starter det å nærme seg, men fortsatt for åpent)
6. “Hvilke negative effekter kan man oppleve dersom teammedlemmene kun gir status til Scrum masteren på morgenmøtet?” (her inviterer man deltagernes kreativitet inn i diskusjonen)

Et eksempel: Å få deltagerne til å tenke gjennom hva de har hørt

Her er noen spørsmål jeg har prøvd å stille til deltagerne etter at jeg har holdt et kurs.

• “Hvordan vil du bruke det du har lært?”: Hvordan-spørsmål blir fort så åpne at deltagerne ikke vet hvor de skal starte
• “Hvilke av teknikkene i Scrum vil være vanskelige å få til i deres organisasjon?”: Hvilke-spørsmål kan være åpne og medføre overfladisk gjennomgang.
• “Hvilken av teknikkene i Scrum vil være vanskeligst å få til i deres organisasjon?”: Hvilken-spørsmål inviterer til å gjøre en mental gjennomgang (som hjelper folk å huske) og begrenser hvor mye hver enkelt føler seg pliktig til å besvare. Egner seg godt for refleksjon på slutten av en workshop.
• “Hva vil du gjøre annerledes etter det du har lært?”: Et tung og forpliktende spørsmål. Effektivt, men må brukes med måte.

Hvilke spørsmålstillinger synes du stimulerer til god diskusjon?

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

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

Hva skjer her?

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

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

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

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

Helt konkret: hvorfor er interaktiv programmering nyttig?

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

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

Jeg bruker jevnlig interaktiv programmering til følgende:

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

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

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

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

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

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

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

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

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

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

Hva har vi sett så langt?

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

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

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

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

Referanser:

A list of REPL environments

Demystifying IRB commands (interactive Ruby)

Secrets of the Rails Console Ninjas

The Firebug Console Panel

Clojure.org: ‘Getting started’

in which are found tricks of the trade concerning clojure authorship

Penumbra OpenGL framework: ‘Getting started’

Impromptu livecoding environment introduction

Andrew Sorenson livecoding videos

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

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

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

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

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

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

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