Her er tre ting du kan gjøre:

Splitt opp på domene

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

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

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

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

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

Splitt opp på operasjon

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

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

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

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

Splitt opp på roller

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

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

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

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

Konklusjon

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

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

Hvilke teknikker bruker du på å bruker historiene dine?

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

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

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

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

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

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

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

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

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

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

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

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!

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!

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.

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

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

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

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

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

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

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

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

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

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

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

Ikke spesielt komplisert.

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

Vel, det finnes dessverre noen utfordringer.

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

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

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

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

Happy testing!

Eksempel:

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

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

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

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

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

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

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

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

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

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

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

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

  return file_changed
end  

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

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

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

test_loop # Start testing!

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

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

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

Øvelse 1: Agile

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

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

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

Øvelse 2: Lean

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

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

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

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

Oppsummering

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

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

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.

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)

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.

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!

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

Planen

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

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

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

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

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

Uortodoks observasjon #1:

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

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

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

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

Virkeligheten

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

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

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

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

Uortodoks observasjon #2:

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

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

Gradvis erstatning

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

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

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

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

Arkitektur

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

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

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

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

Uortodoks observasjon #3:

I store prosjekter er organiseringen den viktigste faktoren i arkitekturvalg.

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

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

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

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

Konklusjon

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

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

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

Vi får til erstatningsprosjekter ved å levere gradvis.

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

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

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

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

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

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

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

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

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

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

Levere verdi

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

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

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

Styre mot mål

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

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

Mer støtte til Produkteieren

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

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

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

Ta erfaring på alvor

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

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

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

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

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

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

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

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

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

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