Tarantell hadde fire deltakere på årets Web 2.0 Expo i San Francisco. Konferansen arrangeres to ganger i året (vår/høst i henholdsvis San Francisco og New York) i regi av O’Reilly media. Tema og bakgrunn for konferansen er Tim O’Reilly’s fellesbetegnelse web 2.0, der hovedformålet var å skape en felles terminologi for alt som endrer vår oppfatning av hva internett er, kan brukes til og hvorledes det påvirker både vår forretningdrift og våre liv.

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:

Det sies at å programmere mot interface er god praksis. Spesielt når man kobler sammen applikasjonen via IoC(Inversion of Control) container som for eksempel Spring, så er det lissom en selvfølge at man skal bruke interfacerer og klasser. Hvor tanken er at brukere av klassen forholder seg til et interface og hvor IoC containeren injecter en bestemt implementasjon av interfacet. Tenken er god, men hva når man kun har en implementasjon av disse interfacene?

La oss tenke oss en trelags arkitektur, hvor man kjører enhets/integrasjonstester helt igjennom helt ned til en testdatabase (som opprettes helt automatisk f.eks via DbUnit). Hva er da hensikten med å lage og vedlikeholde disse interfacene? Slik jeg ser det er det ingen vits. Det skaper kun ekstra arbeid. Mange filer, og mer tungvint utvikling.

Jeg har akkurat opplevd dette hvor jeg har gjennomført programmert mot interfacer, men nå har fjernet alle, og det ser veldig ryddig ut.

Men så kan du spørre, hva om ønsker å injecte dummy test-klasser da? Jo, fint. Det er bare å refakturere. For eksempel så har MyService brukt CustomerDao, og vi ønsker å lage en dummy implementasjon av CustomerDao som heter CustomerDaoDummy. All right. Endre navn på CustomerDao til CustomerDaoImpl og lag et interface som heter CustomerDao som de ulike klassene implementerer. Brukere av klassen trenger man ikke å endre.

Min anbefaling er derfor å ikke programmere mot interface med mindre man trenger det. Du får renere og mer oversiktlig kode på denne måten. Dette er henhold til agile prinsipper og naturligvis KISS prinsippet (Keep It Simple, Stupid).

PS: Det skal sies at dersom man lager biblioteker og funksonalitet som krysser applikasjoner så kan det være hensiktmessig og ryddig med interfaces, men det er ikke tilfellet i en vanlig enkel applikasjon.

Mye har vært tenkt, skrevet og misjonert om metodeverk for utvikling av programvare. Nå har Alan Cooper laget en interaktiv avhandling om hvorledes interaksjonsdesign og brukerorientert utvikling henger sammen med Agile, og hvorledes elementer fra dette (og andre) metodeverk kan bidra til større suksess med løsninger som skal brukes av mennesker.

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. 

Read more »

Dynamisk er fint. Dynamisk betyr bevegelig, effektivt og hensiktsmessig. Dynamisk er et plussord, og udynamisk er et tilsvarende minusord. Dersom man kaller en person udynamisk er det ikke for å rose, skryte og framheve positive egenskaper. Udynamisk er det når ting er helt fast definert, og man (nærmest vrangvillig) ikke ønsker å bevege på dem. Udynamisk gjør det vanskelig å gjøre annet enn det som er faktisk planlagt og avtalt – og gode idéer skal man helst ikke presentere underveis. For å sikre gode vilkår for innovasjon og kreativitet er det derfor viktig å være dynamisk.

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.

For å reparere myten om at alle IT-prosjekter leverer a) For Sent, b) Over Budsjett og c) Med Irrelevant Funksjonalitet er den gjengse oppfatning at svaret har ankommet. Enter Scrum.

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.