Konferansen er et viktig møtepunkt for alle som er opptatt av hva som venter rundt neste hjørne på internett – samt en realitetssjekk på hva som fungerer (eller ikke fungerer) med dagens plattformer, løsninger og forretningskonsepter.

Vi har tatt med oss noen hovedtrender fra Web 2.0 Expo. Hver av dem en verdt en eller flere blogginnlegg, og vi vil komme nærmere tilbake til de enkelte trendene.

Here goes:

Trend #1 : Lokalisering er overalt

Utnyttelse av sosiale medier med lokaliseringstjenester er på alles lepper. De fremste tjenestene pr. nå er businessorienterte Foursquare og tamagotchi/pokemon-inspirerte Gowalla. Google og Facebook er på vei med sine konkurrerende tjenester, så dette skal bli et uoversiktlig landskap å orientere seg i. Det som dog er viktig å ta med seg er:

• Dialog mellom mennesker inneholder stedsinformasjon. Overhør en telefonsamtale på bussen og sjekk selv. Sosiale medier er fremfor alt om dialog, og disse mediene kommer følgelig til å oversvømmes av lokaliseringsinformasjon.
• Virksomheter ønsker å vite både hvem kundene er – og hvor de er. At man også kan bruke sosiale medier til å trekke kunder inn i de fysiske butikkene er ett av Foursquares verdiforslag.
• SFs svar på Ruter (BART) har brukt Foursquare for å øke antall reisende med offentlig kommunikasjon. I en kundeundersøkelse sier 19% av de spurte at de hadde reist med BART basert på en anbefaling fra en digital venn, og 38% syntes offentlig transport var “more fun” med mobile lokaliseringstjenester.

Lokaliseringstjenester kommer til å bli stort – og forhåpentligvis mer oversiktlig enn det er idag.

Trend #2 : HTML5 er den nye vinen

Hva skal man si? ALT kan gjøres i HTML5. Audio, video, skalerbar vektorgrafikk, 3D, SQL, webfonter etc. etc. Dette kan erstatte Flash, Silverlight og andre pluginbaserte utvidelser. De dårlige nyhetene er at implementeringen varierer kraftig fra nettleser til nettleser, og Microsoft er ikke på banen ennå. Vi står med andre ord foran flere år med browserkrig. Google har prøvd å imøtegå dette ved å lage en Chrome plugin til IE, noe som virker som et solid hopp tilbake til start.

En engstelig sjel i salen som prøvde å varsku om sikkerhets- og ytelsesproblemer fikk klar beskjed fra podiet: Toget har gått; standarden er vedtatt, framtiden er her og nå.

Så fikk vi se og høre Quake 2, spilt i nettleseren. Wow.

Trend #3 : Weboptimalisering

Ytelsesoptimalisering av websider gir høyere kundetilfredshet, økt konverteringsrate, mer aktive brukere – OG det er lønnsomt ift reduserte krav til infrastruktur og drift.

For å ta det siste først: Siden det å servere ut html-sider er noe av det tyngste infrastrukturen din gjør, har tjenester som Netflix og Shopster redusert henholdsvis antall servere og båndbredde til det HALVE ved å drive strukturert og helhetlig optimalisering av websidene. Sjekk ditt eget driftsbudsjett for å se hva gevinsten kunne vært? Forutsetningen for en slik kostnadsreduksjon er selvfølgelig at man har et stort antall brukere – og at man betaler for faktisk bruk av infrastrukturen (slik man gjør i skyen…).

Google og Yahoo! har foretatt undersøkelser med brukere som blir utsatt for dårlig ytelse. Begge undersøkelsene utsatte brukere for høyere og høyere forsinkelse i levering av websider. Undersøkelsene ble ikke framlagt, men en viktig lærdom fra Google sin undersøkelse er verdt å merke seg:

Google kjørte undersøkelsen med testgruppe og referansegruppe, der referansegruppen ikke ble utsatt for forsinkelser. Testgruppens adferd endret seg, i form av at brukerne ble mer passive, mindre villige til å fullføre oppgaver (=lavere konverteringsrate). Etter at forsinkelsen ble fjernet hadde gruppene fortsatt ulik adferd – i lang tid. Så lang tid at testgruppen ikke hadde fått gjenopprettet sitt aktivitetsnivå idet undersøkelsen ble avsluttet. Brukere som blir utsatt for forsinkelse blir passive, og det gir ingen umiddelbar effekt å rette feilen.

Ved dårlig servicenivå gjør man skade som varer lenge.

Virksomheter som har hatt suksess med weboptimalisering sier at verktøyene ikke trenger å være veldig sofistikerte. De trekker fram Yahoo! YSlow og Google Page Speed som gratiseksempler. Men et viktig suksesskriterie er at ytelsesparametrene ikke kan eies av IT alene: Alle de viktigste ytelsesparametrene må eies (og forstås) av forretningsenheter, markedsavdeling og ledelse. Først da kan man ta ut den forretningsmessige effekten.

Trend #4 : API’er på godt og vondt

Fra å snakke om mashups er dialogen og diskusjonen nå vendt til realitetene ved å eie, forvalte og bruke åpne API’er. Mantraet fra LinkedIn er: Planlegg godt, gjør ingen feil. Lett å si, men vanskelig å gjøre.

Twitter har hatt store problemer med sin autentiseringstjeneste, og har måttet tvinge brukerstedene av API’et over på ny løsning – rett og slett ved å skru av den gamle på et gitt tidspunkt. Resultatet ble at mange tjenester som baserte seg på twitter sluttet å virke, og feilsøking og feilretting rundt overgangen er fortsatt ikke avsluttet. Litt mer kundevennlige LinkedIn måtte ringe opp alle brukerstedene før de gjorde endringer. God service, men en så stor jobb at det nesten er vanskelig å forestille seg.

Lærdom1: Skal man etablere et åpent API må man betrakte brukerne av API’et som kunder, og behandle dem deretter. Å eie et API er å eie et produkt – lansering må planlegges nøye, og produktets livssyklus må analyseres før det settes ut i markedet.

Lærdom2: Skal man benytte et åpent API må man agere som kunde. Dette innebærer å registrere seg, og forholde seg til løpende dokumentasjons- og programendringer. Man må også ytelsesplanlegge og robustifisere sin egen løsning og kundedialog for situasjoner der API’et kan være utilgjengelig.

Trend #5 : Sosiale medier og CRM

Alle vil vite mer om hvorledes man kan benytte sosiale medier i aktiv bearbeiding av markedet og kundene – med økt salg som formål. Mange vil snakke om temaet, og har kloke ideer til hva man ikke bør gjøre. Nesten ingen har gode mønster/patterns for hvorledes gjøre dette i praksis.

Lærdom: Det er bedre å gjøre noe selv om man ikke ser en konkret og målbar positiv effekt, enn å gjøre ingenting og oppleve en konkret og målbar negativ effekt.

Trend #6 : Vi er alle (agile) webutviklere

Sett i lys av ovenstående trender blir webutvikling og kunnskap om tjenester og teknologier en felles møteplass for forretningsutviklere, systemeiere, markedsførere, designere og utviklere. Ingen kan melde seg ut av denne kunnskapssirkelen og fortsatt ha et realistisk håp om fantastiske resultater ved bruk av digital teknologi. Web 2.0 tilhører ingen rolle, avdeling eller virksomhet alene.

For å skape god effekt med mange involverte parter, satte konferansen søkelyset på hurtigd/agile/lean prosesser der man skaper verdi tidlig – og prioriterer hardt i forhold til egne krav. Levere lite & fort er bedre enn mye & sent.

Alt satt i system

I et forsøk på å sette disse trendene i en form for et system, skisset jeg raskt opp denne figuren på det man bare måtte ha med seg hjem fra San Francisco i mai i år: en iPad. Rundt en tredel av alle konferansedeltakerne hadde et brett, og på forespørsel fra plenumspodiet kom så godt som alle hender i været på spørsmålet: “Hvem har en iPhone?”. Tross denne Apple-dominansen var det slående at sympatien vektet tungt i favør av Adobe i spørsmålet rundt framtiden til Flash. Dette er kanskje også trender, men her har vi satt fokuset på forretningsutvikling på nett:

Kundeopplevelse og Web 2.0 trender

Tyskerne krever 945 piksler for at de skal kunne innarbeide det gylne snitt, men portugiserne står hardnakket på 925 og har allerede begynt å implementere… hva skal jeg gjøre? Hva er riktig?

Utsagnet oppsummerer kundens situasjon: Stor organisasjon med regionale aktører og egne meninger på kollisjonskurs med behovet for et enhetlig og konsistent design. Kunden har innsett at det sistnevnte gir både kommunikasjonsmessige og økonomiske gevinster, men får problemer i møte med tilsynelatende vilkårlig valgte tall som det plutselig er gått nasjonal prestisje i.

La oss passere nasjonal selvfølelse i stillhet: Hvordan velger du egentlig optimal bredde på en nettløsning? Svaret er, som med mye annet i livet, at det kommer an på. Heldigvis kommer det ikke an på så fryktelig mye, og vi skal se på det viktigste her.

Fast eller fleksibel

Høyde

Med unntak av statiske online-reklameplakater, microsites, kampanjer og en og annen webapplikasjon, har nettsider som oftest fleksibel høyde. Denne utformingen rommer mulighet for variable mengder av innhold i form av tekst, bilder og andre media, og forskjellig presentasjon av dette materialet avhengig av kontekst. Scroll-hjul på musen har gjort det helt naturlig å flytte siden oppover etterhvert som man skummer gjennom en artikkel eller skaffer seg oversikt i en portal – faktisk er det ofte langt mer irriterende å måtte “klikke for å gå til neste side” enn bare å la siden gli over skjermen. Personlig mener jeg at med unntak av ved svært store datamengder eller ved behov for å eksponere brukerne for stadig nye bannerannonser er sideskift uten et samtidig skifte av kontekst eller tema en uting på internett.

Bredde

Når det gjelder bredden har man i utgangspunktet 2 valg: Fast eller fleksibel bredde. Det er fordeler og ulemper ved begge disse. Ikke alt innhold egner seg til fri skalering i bredden, men dette får bli gjenstand for et annet blogginnlegg. Det er ihvertfall stadig diskusjon om hva som fungerer best i de enkelte tilfellene, og Dagbladet hadde nylig en artikkel vedr. nettavisens redesign til å bruke fullskjermbredde uansett skjermstørrelse. Men uansett hva du velger må du finne den optimale størrelsen eller minste-størrelsen for nettsiden din. Hva som er riktig størrelse kommer an på både tekniske og kommunikasjonsmessige forhold:

Sjekkliste for å finne optimal nettsidebredde

Denne listen starter med spørsmål som er almenngyldige for alle designprosesser og blir mer direkte relevant etterhvert. Kommunikasjonskanalen er i dette tilfellet er bestemt: Internett.

1. Hvem snakker du med?

God kommunikasjon avhenger i stor grad av kjennskap til hvem man snakker til eller med. Ha et klart bilde av hvem du forsøker å nå – hvem skal bruke nettsidene dine, hva skal de oppnå, hvilke forutsetninger har de, osv. Med en nettstrategi i ryggen kan du gjerne bruke  personas eller andre verktøy for å etablere gode, klare svar på dette.

2. Hvilken fysisk skjermbredde har de?

Det som ofte veier tyngst i å avgjøre nettsidenes bredde, er hvilke tekniske forutsetninger brukerne har for å se sidene – mao. hvilken skjermbredde og skjermhøyde de ser løsningen med. Dette er det mulig å svare mer eller mindre presist på:

1. Dersom nettsidene skal utgjøre et intranett i en stor organisasjon med en IT-avdeling med rutiner som får “Prosessen” av Kafka til å blekne er svaret ofte veldig enkelt og veldig presist: Alle har akkurat samme skjerm med akkurat samme oppløsning. Uansett. I slike tilfeller har alle forresten også samme nettleser – det gjør det i teorien lettere å utvikle spesialfunksjonalitet til intranettet – men ikke sålenge nettleseren heter Internet Explorer 5 – kom igjen folkens: Oppgrader!
2. Dersom nettsidene retter seg mot offentligheten må vi istedet gjøre antagelser basert på hva vi vet om brukerne. Vi kan undersøke forhold som f.eks. deres brukssituasjon (hjemme eller på jobben?), yrke (grafisk designer eller lokomotivfører?), interesser (ornitolog eller power-gamer?), og andre demografiske data for å si noe om nivået på deres typiske IT-investering.
3. Sist men ikke minst kan vi basere oss på eksisterende nettstatistikk for brukere av tjenester som har lignende profil som den man selv skal lage. Fordelingen av brukere på skjermoppløsninger i løpet av første halvdel av desember for 2 store norske internettjenester med svært bred publikumsappell var som følger (grunnlaget baserer seg på mellom 2 og 3,5 millioner unike treff, og oppløsninger med samme bredde er slått sammen til ett tall):
   

   Oversikt over skjermstørrelser for unike besøk på 2 store norske nettsteder 2 uker medio desember 2008

   Tallene viser at det er forskjell på hva folk benytter på jobb og hjemme, og viser også at det brede laget av befolkningen i alle situasjoner besitter et minimum på 1024 x 768 piksler.

3. Hva er den maksimale bredden?

Med en skjermbredde som er rimelig ifht. brukernes forutsetninger må vi finne ut hvilken bredde vi egentlig har til rådighet. Poenget er å ikke definere en så bred side at man får horisontal rullesjakt* når nettleservinduet er maksimert og har vertikal rullesjakt. Forskjellige operativsystem og nettlesere “spiser” litt forskjellig av den totale skjermbredden til å vise nettleservinduets kanter og den vertikale rullesjakten. Som en tommelfingerregel bruker vertikal rullesjakt 16 piksler i bredden. I tillegg bruker enkelte nettlesere opp til 8 piksler på hver side for å tegne kanten på nettleservinduet. Dermed går altså 8+8+16 = 32 piksler i utgangspunktet tapt i bredden. På en typisk skjermoppløsning på 1024 x 768 sitter vi da igjen med en maksimalbredde på 1024 – 32 = 992 piksler.

Hva da med brukere som har installert/aktivert tilleggsmenyer i nettleser/operativsystem som også tar opp verdifull plass i bredden? På Windows dreier dette seg  primært om en “sidebar” i Vista (som Google har laget et alternativ til). På Mac er det mulig å plassere Dock’en på høyre eller venstre side og sette den til å ikke automatisk skjules. Dette spiser verdifull skjermplass. Skal vi ta hensyn til brukere som gjør dette? Med forbehold om spesielle forhold ved nettsidenes funksjon vil jeg stort sett svare nei. En bruker som bevisst endrer oppsettet så det avviker fra standardoppsettet er klar over at dette er gjort, samtidig som slike brukere statistisk sett er del av et svært lite mindretall. Det er også rimelig å anta at slike brukere med stor sannsynlighet ikke sitter med den minste tilgjengelige skjermstørrelsen heller – og da er det uvesentlig om 30-40 piksler ekstra går tapt.

(*”Scroll-bar” heter faktisk “rullesjakt” på norsk. Som innvandret brite får jeg gåsehud av begreper som dette, men forsøker altså å holde språket norsk her. Uoffisielt forslag for “roll-over” er forresten “Overglidning”. Brrr.)

4. Bruksmessige hensyn

Hvordan nettsidene skal fungere, dvs. hva deres oppgave er ifht. brukeren samt hvilket etterlatt inntrykk brukeren skal sitte igjen med, er en minst like vesentlig faktor som fysisk og virtuell skjermbredde. I enkelte tilfeller dikterer hensynet til nettsidenes funksjon hvilken skjermstørrelse man skal optimalisere nettsidene for, fremfor at minste felles multiplum for skjermstørrelse skal gjelde slik at “alle” kan se sidene optimalt.

Big is always beautiful

Det er ingen absolutte regler for hva slags type side som bør ha stor eller liten plass. En portal eller nyhetsside “trenger” i utgangspunktet mer plass i bredden enn en blogg: Dette er sideoppsett som gjør aktiv bruk av flere spalter og seksjoner for på en visuell måte å prioritere store mengder informasjon. Likeledes vil en side som skal fungere som arbeidsflate – som et intranett dashboard eller en webapplikasjon – ofte nyte godt av større plass. Men selv en blogg eller en kampanjeside bruker stor skjermplass med fordel – innholdsområdet kan utformes smalt eller lite, men ekstra plass rundt innholdet skaper ro og fokus på budskapet.

Jeg kommer ikke på noen tilfeller der nettsider har en stor fordel av å være små (vi snakker nettelsere og skjermer, ikke wap og håndholdte devices nå). De tilfellene finnes nok, men i min verden blir dette i større grad en designmessig avveining – det er alltid gunstig å ha stor plass å boltre seg på, og hvis det innenfor rammen av tilgjengelig skjermbredde ikke er noe ved bruksegenskapene som tilsier at sidene bør ha liten bredde kan hele flaten gjerne gjøres tilgjengelig for formgivning – enten det endelige arbeidet oppfattes som avgrenset innenfor et rolig passepartout eller ikke.

5. Hvordan dele opp flaten?

Vi har funnet skjermstørrelsen vi ønsker å basere oss på og har trukket fra nok til å gi oss en sikker maksimumsbredde. Hvordan bestemmer vi om den endelige bredden optimalt skal være 992 eller f.eks. 945 (som i eksempelet med det gylne snitt) eller 925 piksler? Dette er et designspørsmål, og her kommer designerens beste venn – grid’et – inn i bildet.

Grid

Et grid er i all enkelhet et rutenett med en konstant avstand mellom alle vertikale og alle horisontale linjer. Poenget med grid er at man benytter det som et skjelett å bygge designet på – man sørger for at vesentlige visuelle elementer går kant i kant med linjene i grid’et. På denne måten oppår man ryddighet og stramhet i designet – det at forskjellige elementer flukter med hverandre på tvers av formatet skaper ro og klarhet. Et grid kan ha store eller små ruter – mindre ruter gir i utgangspunktet større fleksibilitet. Et grid er ikke en tvangstrøye: Grid’et kan brytes bevisst for å oppnå en ønsket effekt. Dette er grunnleggende designkunnskap, og Khoi Vinh og de fine folkene på A List Apart har laget artikkler som viser bruken av grid på en kjempebra måte.

Eksempel på side som bruker grid

Eksempel på side som ikke bruker grid

Som du sikkert allerede har gjettet – størrelsen på rutenettet i gridet, kombinert med hensyn til hvor mange og brede spalter man ønsker i sideoppsettet, avgjør hva som er en hensiktsmessig pikselbredde for nettsiden. Noen eksempler belyser dette best:

3 eksempler på utregning av sidebredde

Hvilket antall kolonner og hvilken bredde/høyde på hver grid-rute som er riktig for nettstedet eller de enkelte sidene i nettstedet er en vurderingsak i hvert tilfelle. Dette er et puslespill hvor man gjerne tar hensyn til:

• Hva og hvor mye skal med på en gitt nettside? (Informasjonsarkitektur)
• Er det forhåndsbestemte mediaelementer som skal fungere i grid’et (f.eks. video eller reklamebannere i standardstørrelser)?
• Hvilken gridstørrelse er formålstjenlig ifht. formspråket – er det lettere å sette opp sidene med mindre ruter eller større ruter?

Personlig liker jeg å jobbe med grid som baserer seg på tall som er lette å dele på hele antall piksler, f.eks. 32 som lar seg dele på 2, 4, 8 og 16, eller 24 som lar seg dele på 2, 3, 4, 6, 8 og 12. Når og hvis omstendighetene tilsier at grid’et skal brytes blir det på denne måten lett å gjøre det på en måte som harmonerer med grid’ets basistall.

Grid er forøvrig ikke bare til hjelp som et verktøy for design. Det finnes flere rammeverk i CSS som gir støtte for svært effektiv implementasjon av nettsider ved bruk av grid. Et godt eksempel er Blueprint CSS som lar deg definere et grid i tråd med det du har benyttet ved design av nettsidene, og som deretter genererer CSS som enkelt lar deg posisjonere elementene i forhold til dette grid’et.

Det gylne snitt

Vi har funnet optimal bredde for nettsiden vår, og definert et bra grid vi kan jobbe med. Men hva var egentlig det snakket om det gylne snitt i starten av innlegget?

Det gylne snitt er et forholdstall som har lang historie innen arkitektur, kunst, design og musikk. Mange menneskeskapte verker bærer i seg det gylne snitt, og tallet finnes også igjen i mange former i naturen. Det gylne snitt defineres ved at man deler en linje i en lang og en kort del, hvor forholdet mellom den lengste delen og den korteste delen er det samme som forholdet mellom hele linjen og den lengste delen av linjen. Wikipedia har en forklarende artikkel.

Jeg ble overrasket over referansen til det gylne snitt i kontekst av nettsidebredde. Det er tradisjonelt et begrep som hører mer til design for papirtrykk enn for piksler. Når det er sagt er det er ikke noe galt i å forsøke å innarbeide dette prinsippet, men det virker nokså tynt å skyve det foran seg som en forklaring på hvorfor man akkurat måtte bruke 945 piksler, særlig når man ikke kommer inn på hva 945 skal stå i forhold til. Det gylne snitt er et interessant forholdstall som kan gi vakre proporsjoner. Det er et virkemiddel som kan vurderes brukt på samme måte som andre virkemidler – ikke et slags komposisjonsmessig dogme som må etterkommes for enhver pris og uten spørsmål. Et godt grid vil stort sett gjøre mer for kvaliteten enn det å innarbeide det gylne snitt for ett eller flere forhold på nettsiden din.

Uten mulighet til selv å ta tak i formgivningen som var utført for kunden anbefalte vi på generelt grunnlag å benytte den største av de to skjermbreddene som det allerede var sunket tid og penger i å utvikle,  basert på prinsippene vi har vært innom her. I og med det tyske kontoret dermed har fått viljen sin får vi håpe at også det gylne snitt vil bidra til å heve det ferdige produktet.

Dette må være obligatorisk lesing for alle som bidrar til utvikling av programvare – enten man er produkteier, kunde, bruker, kravstiller, leder, interaksjonsdesigner, systemarkitekt, programmerer eller tester. Og for en gangs skyld er jeg ganske overbevist om at alle kan enes om en felles referanseramme. Istedet for å starte en ny debatt om hva som er det ene, korrekte svaret.

Nyt bildene, nyt innsikten – dette er nesten magisk:

http://www.cooper.com/journal/agile2008/

Større systemer og applikasjoner er som regel delt opp i horisontale lag. De øverste lagene er nærmest sluttbrukerne og de nederste lagene er nærmest databasen og de eksterne systemene. Lagene i midten håndterer forretningslogikk. 

Hvordan skal man gå frem for å utvikle et stort system? Vi tar for gitt at fossefallsmetoden er foreldet og at vi ser oss om etter en mer smidig (agile) prosess. I tillegg til Scrum og Extreme Programming (XP) finnes det en metodikk kalt “Feature Driven Development” (FDD) som er utviklet av Jeff de Luca og Peter Coad. 

Hvis man setter funksjonalitet i fokus, kan man tenke seg at funksjonalitet skjærer vertikalt gjennom alle lagene. For å implementere use casen “Registrer ny kunde” trengs det sannsynligvis brukergrensesnitt, forretningslogikk, integrasjon og datalagring.

Tanken bak FDD er at planlegging, design og utvikling styres av funksjoner, og at funksjoner utvikles en etter en selv om de berører alle de horisontale lagene i systemet.

En kort forklaring på hvordan FDD virker:

1. FDD starter med modellering. Domene-eksperter forklarer forretningsdomenet til utviklerne. Dette dokumenteres.

2. Forretningsdomenet deles opp i områder som igjen har aktiviteter. Aktivitenene beskrives som “features” på en formell måte som minner om use cases. Features skal ikke tar mer enn 2 uker å utvikle.

3. Planlegging skjer ved at aktiviteter fordeles på utviklingsteam.

4. Design av en feature.

5. Utvikling av en feature.

Forskjellige utviklingsteam kan jobbe i parallell med forskjellige features. Erfaringer etter at en feature er ferdig mates tilbake til modellen som ble beskrevet i punkt 1.

Fordelen med å jobbe på denne måten er man ender opp med fungerende software, ikke bare moduler som virker i seg selv, men som er avhengig av andre moduler for å anses som komplett. Et utviklingsteam vil også få en eierfølelse og et ansvar for en hel feature, ikke bare en del av av systemet.

Alt dette er vel og bra, og case studies beskrevet av Butler Group viser til store innsparinger ved bruk av denne metodikken.

Jeg kan ikke forstå annet en at denne utviklingsmetodikken vil sette veldig store krav til kommunikasjon mellom de forskjellige utviklingsteamene for å unngå duplisering av arbeid. Jeg vil også tro at en stor grad av refactoring blir nødvendig etter hvert som nye features implementeres. 

Som vanlig er litteraturen som omhandler denne metodikken full av store ord og generelle vendinger, men ikke så veldig mye om eventuelle negative sider eller ting man bør passe på i FDD-prosjekter. 

Hvis noen har erfaringer med bruk av FDD i praksis, så del dem gjerne med andre ved å kommentere dette innlegget.

Mer om Feature Driven Development finner du her:

http://en.wikipedia.org/wiki/Feature_Driven_Development 

http://www.nebulon.com/fdd/index.html

http://www.featuredrivendevelopment.com/

I Tarantell leverer vi prosjekter. Prosjekter er (av andre enn oss) definert som å være “ikke-repeterende” arbeidsoppgaver. En form for dugnad, der man setter ned en arbeidsgruppe eller prosjektgruppe på tvers av linjeorganisasjonen; på tvers av ordinære ansvar og oppgaver. En prosjektgruppe har mandat til å løse én bestemt oppgave, innenfor gitte tidsrammer og budsjettrammer.

Et prosjekt kan i sin natur ikke gjentas. Om det kunne, ville det vært en prosess, en produksjonsprosess – som gjerne kunne inngå i en industribedrift. Måten man lager hamburgere på hos McDonalds er en slik prosess: man følger de samme stegene og kommer til det samme resultatet. Gang på gang, i et repeterende mønster.
I et prosjekt kan man gjenbruke erfaringen og kunnskapen som ligger igjen hos prosjektdeltakerne, men prosjektet i seg selv er for unikt til å gjentas steg for steg.

Gjennom denne ganske raske argumentasjonsrekken kan man trekke den slutningen prosjekter (som er unike) har behov for dynamikk (for å sikre nødvendig innovasjon og kreativitet). Dynamiske prosjekter burde derfor være et plussord som var mye brukt. Men det er det ikke. Istedet hører man mye om agile prosjektmetoder, smidighet, fleksibilitet og effektivitet. Dette er verktøy for å nå prosjektets målsetning – ikke for å påvirke prosjektets målsetninger. Den kreativiteten og innovasjonen man gir rom for er for å levere det beste resultatet – ikke for å omdefinere behovet.

Det er viktig å se denne forskjellen, slik at man legger til rette for den rette bruken av alle kreative krefter (og de er mange!). Prosjekt som arbeidsform er i de fleste tilfeller lagt opp som en relativt rigid og udynamisk gjennomføring. Man har fastsatte budsjettmidler, en fast tidsramme og et fast team av mennesker til å løse oppgaven. At teamet eller arbeidsgruppen har behov for en smidighet i sin gjennomføring er lett å se: Når alt annet er fastlagt, er det kun den mennesklige tilpasningsevne som kan dekke opp for uforutsette forhold (og de er det OGSÅ mange av!).

Finnes det da ikke dynamiske prosjekter der ute? Prosjekter der målsetningene defineres basert på en kontinuerlig læringsprosess?
De finnes. Men jeg er ikke sikker på om det gjør prosjektgruppens arbeid noe enklere. I dynamiske prosjekter vil man arbeide på et høyt abstraksjonsnivå; og man er nært koblet til forretningsstrategi og bevilgning av midler. Dette gir helt andre leveransetyper enn de man er vant til i mer rendyrkede utviklingsprosjekter. Man vil f.eks. levere en idé, et mandat, en beslutningsunderlag – kort sagt et premiss for å gjøre den endelige leveransen. Og det er noe ganske annet enn en å komme til en sluttført løsningsleveranse.

Med hurtige iterasjoner, fokus på burn down og team som ikke konstant forstyrres av endrede krav er framtiden allerede ankommet. Veien blir målet, vi reiser sammen og alle ender på samme sted, på samme side i boken, funksjonaliteten er som avtalt, kvaliteten er i henhold til planlagt nivå – og tid og kostnader er under kontroll.

Andre, gammeldagse metodeverk konsentrerer seg om å planlegge før man går til aksjon – også kalt fossefall. Noen helt klare ulemper med dette er at fossefallsprosjekter har en tendens til å vare lenge, og de kravene man hugde i steintavlene ved prosjektets start er kanskje ikke like viktige lenger. Kostnadsrammene er fastsatt, og rigid endringshåndtering sørger for at det er vanskelig å omprioritere kravene underveis. Dersom man allikevel velger å endre kravene blir tidsrammene forskøvet og man må tilføre mer budsjettmidler. Fordelen, vil mange hevde, er at det er langt lettere å knytte dette til standard kontrakter og juridiske avtaleverk.

I hverdagen oppleves det slik at fossefallsprosjekter betinger en god del støtteleveranser. Dokumentasjon. I utgangspunktet vil det være en god idé å dokumentere sine planer og veivalg, slik at partene er enige om hvilke prioriteringer prosjektet har gjort. Men ofte er det slik at: a) leverandøren må sette av produksjonskapasitet (les: programmerere) for å dokumentere, og b) oppdragsgiver ikke har kompetanse eller tilgjengelig tid til å vurdere planene.

Dersom man i korte iterasjoner KODER i stedet for å dokumentere vil man være produktiv tidligere, og det blir enklere og mer oversiktlig for oppdragsgiver å ta stilling til resultatet, og å prioritere den viktigste funksjonaliteten. At standard kontraktsverk ikke ennå støtter denne partnerorienterte arbeidsformen skal jeg ikke komme nærmere inn på her.

Men: I prosjekter av strategisk natur vil ikke løsningsområdet være tydelig. Målsetningen kan være å øke inntekter; å redusere kostnader; å søke nye forretningsmuligheter. Å starte å kode noe på dag 1 vil i slike tilfeller være en relativt sikker måte å ødsle med tid og penger på. Man vil ikke kunne vite om man er på riktig plattform, med riktig personell, og man kan bare gjette på hva kravene til løsningen kan være.

Ingen fare, sier scrummerne. Scrum kan brukes til alt mulig, også strategiarbeid. Dette er selvsagt 100% korrekt, gitt at HELE prosjektet dreier seg om strategi. Men dersom første iterasjon dreier seg om strategisk fundament, andre iterasjon vil dreie seg om plattform- og leverandørvalg, tredje iterasjon om etablering av infrastruktur etc. har jeg følgende påstand: Dette er fossefall. Og det er fossefall med en uhensiktsmessig metode. Teamet vil måtte endres fra iterasjon til iterasjon, backlog kan ikke videreføres, koding må avvente anskaffelse og leverandørvalg etc. I slike tilfeller vil man være langt bedre tjent med å splitte opp i flere og mindre prosjekter. Eller å benytte en velprøvd fossefallsmodell med faseinndelinger, formaldokumenter og beslutningspunkter.

At Scrum inneholder samspillsregler og oppmuntrer til god internkommunikasjon i prosjektgjennomføring kan bare applauderes. At man har fokus på produktivitet og klare ansvarsforhold likeså. Men som verktøy må det være tilpasset oppgaven.

Hørt om Ta-da og Backpack? David Heinemeier Hansson hos 37signals er programmereren og evangelisten bak disse applikasjonene. Han er nå leder for videreutviklingen av det ikke helt ukjente rammeverket Ruby on Rails og har svært klare ideer om hvordan utvikling av webapplikasjoner skal foregå.

Etter en obskønt amerikansk intro sparker Hanselman moroa i gang : Må HTML vike for rikere presentasjonsteknologier som Apollo og Silverlight? Hansson tar resolutt til motmæle og omfavner HTML/CSS/JavaScript for begrensningene og konvensjonene det gir. Orginalitet er ikke nødvendigvis en god ting i UI design, de tradisjonelle teknologiene gir både brukere, designere og utviklere kjente modeller å jobbe med. Hansson ser ingen grunn til å finne opp flere hjul. Fowler kunne vanskelig vært mer enig, rike klienter er fint og flott til fancy gadgets, widgets og desktopapplikasjoner men mangler rammene som HTML med venner gir. Folk flest takler ikke friheten som følger med et blankt ark, og dette vil gå på brukervennligheten løs. Verktøy og muligheter kommer i fokus og interaksjonsdesignet havner på sidelinjen. Gode prosesser som forener smidig utvikling og usability er områder som behøver ytterligere fokus ærklærer Fowler og jeg kjenner jeg blir litt rørt.

Designet må komme først og gjerne tett påfulgt av HTML – design er ikke pynting som vi legger på toppen etterpå, men utgangspunktet for applikajsonen. Heinemeier Hansson tror designere tåler litt Ruby kode i HTML’en sin og i tillegg skal man strebe etter å få reelle data på lufta så fort som mulig – “lorem ipsum” må gå. Funksjonelle spesifikasjoner trenger vi heller ikke, applikasjonen er spekken og hvis vi ikke liker den så forandrer vi den, når som helst, og hvor grunnleggende som helst. Fowler stepper inn med presiseringer: Design først, men ikke for mye. Virkeligheten forandrer seg for ofte til at man kan gå tre måneder i tenkeboksen og tegne opp hvert eneste skjermbilde. Man skal utvikle i små steg og være forberedt på endring, nøkkelord her er Enhetstesting og rammeverk. Jeg kjenner at jeg nikker og smiler.

Diskusjonen vender seg mot estetikk i kode og hvordan strengt dogmatiske rammeverk tvinger utviklere til å gjøre ting pent og riktig helt fra starten av samtidig som det avler engasjerte sjeler. For debattdeltagerne er trenden er tydelig: alfautviklere og tilsvarende kunder går bort fra Microsoft og fossefallsmetode til fordel for mer engasjerende metoder og teknologier – med andre ord: Agile og Rails.

Podcasten i sin helhet finner du her:
http://www.hanselminutes.com/default.aspx?showID=82

Namedropped:
Jeff Patton
Marc Mcneill
Treesurgeon
Magic ink manifesto

Fritt sammendratt av
Stephan Winter

Selv om man oppdager og unngår slike feil, vil man ikke nødvendigvis få et raskt og effektivt utviklingsløp, sier han. Men ved å gjøre disse feilene vil man få et lenger prosjektløp enn nødvendig.

Mange av disse klassiske feilene er nok velkjent for de fleste, og det er beskrevet måter å unngå flere av dem. “Adding people to a late project” feilen, ble så tidlig som i 1975 beskrevet i boken The Mythical Man-Month av Fred Brooks, men fortsatt er det prosjektledere som synes at tanken om å bli fortere ferdig ved å tilføre flere hoder, er besnærende.

Artikkelen til McConnell er interessant for alle som er involvert i utviklingsprosjekter, og kan fungere fint som en sjekkliste for å bidra til at et prosjekt holder riktig kurs.

Artikkelen finner du her: http://www.stevemcconnell.com/rdenum.htm

Sett med mine Focus Dailies® så er dette morsom og viktig lesning. Agile metodikk har gjerne et utviklerperspektiv hvor den enkelte utvikler igjennom f.eks. personas eller kundekontakt ivaretar brukervennligheten i løsningen. Dette er vel og bra men erstatter ikke kvaliteten de tyngre UCD metoder og utøvere produserer. Ambler foreslår gjensidig tilnærming og kompromisser men tar han fortsatt for lett på UCD? – Kjør debatt.

http://www.agilemodeling.com/essays/agileUsability.htm