Hundreogførti tegn i rampelyset
Gjesteblogg om Twitter, skrevet av Are Wold. Are er Seniorkonsulent i Capgemini og jobber til daglig som utvikler i NAV. Are er forøvrig en rutinert blogger og en aktiv meningsytrer på Twitter og andre sosiale medier
Som Twitter-bruker føler jeg meg iblant som en sjiraff skvist inn i en skikkelig liten Lada på den globale informasjonsmotorveien. Hvorfor det? Og hva skal man med et så ukomfortabelt transportmiddel? Jo, nå skal du høre.
En global tankestrøm
Trykk deg inn på http://search.twitter.com, og vips - du kan bade i hele verdens tanker. Millioner av nettbrukere skryter, drømmer, klager, jamrer, syter, gleder seg, krangler og forteller. Jeg kjenner ikke til noe som når opp til Twitter på dette punktet. Hva tenker verden om Jarlsberg, for eksempel?
I samfunnet vårt, hvor titalls millioner følger med på de samme begivenhetene samtidig, gir dette fascinerende muligheter. Jeg fulgte minnekonserten for Michael Jackson, der Brooke Shields holdt en følelsesladet tale hvor hun refererte til... "Den lille prinsen", Saint-Exupéry kjente barnebok?! Jeg lurte på om jeg hadde hørt feil, eller misforstått, men et kjapt søk på Twitter bekreftet at dusiner av andre TV-tittere verden over hadde gjort den samme observasjonen (og var like overrasket).
Gir deg tilgang til de enkeltmenneskene du er interessert i
Et sted i verden fins det garantert mennesker som er opptatt av akkurat det du brenner for - og med Twitter kan du får en kommunikasjonskanal til disse folkene, samt få med deg hva de sysler med og hvilke tips de har. Jeg er mobiltelefonentusiast, og hadde stort utbytte av dette i tiden før N97 ble lansert, da betatestere delte sine inntrykk over Twitter. Dette henger sammen med neste punkt:
Gir store selskaper et menneskelig ansikt mot verden
Enkelte firmaer bruker sine Twitter-feeds til å fortelle verden at de har lagt ut en ny pressemelding. Gjesp! Twitter kan være et konkurransefortrinn for selskaper når de bruker mediet som en selvstendig kommunikasjonskanal, hvor kunder kan ta kontakt og få svar på direkten, og "tilfeldige forbipasserende" kan se at selskapet har en personlighet i det offentlige rom. Et eksempel er OviByNokia, som opplagt er en aktiv satsning fra Nokias side om å være til stede og ha en egen stemme på nett. Twitter-strømmen er en blanding av produktinformasjon, tips til bruk av Nokias utstyr og svar på direkte spørsmål fra brukere.
Skiller "en du er venn med" fra "noen som ytrer noe interessant"
De fleste av oss er med i et sosial nettverk hvor "venner" kan spamme oss med mer eller mindre irriterende statusoppdateringer. Man kan jo ikke like godt bli uvenner med Kari selv om Kari forteller om alt for mye du overhodet ikke bryr deg om. Heldigvis har Facebook innført filtreringsfunksjonalitet, slik at du slipper å få statusoppdateringer, også fra de som er dine "venner" - men det å være venn på Facebook vil i seg selv implisere at du følger litt med på personen.
Twitter blander ikke kortene - her følger du noen fordi du er interessert i statusoppdateringene, og er du ikke interessert i dem, da følger du ikke med lengre. Enkelt og greit. Eller ikke? Prestisjen rundt det å ha mange followers, brukere som leser feeden jevnlig, kan spille inn - men dette kommer jeg ikke inn på her.
Er vidåpen
Twitter er åpent! Du kan lese en hvilken som helst twitter-strøm ved å gå inn på http://twitter.com/<brukernavn>. Twitter har mange API'er åpent tilgjengelig, så tredjepartsutviklere kan kjapt koble seg på og lage programvare for tjenesten. Motstykket for min del er Facebook, som i utgangspunktet kun lar venner se dine statusoppdateringer, og krever at du er medlem for å kunne være venn.
Dette er mange gode grunner til å bruke Twitter. La oss se på sjiraff i Lada-aspektene ved tjenesten...
Verdens største ekkokammer
Du har ikke brukt Twitter lenge før du lærer begrepet "RT", eller "retweet". Dette innbærer å ta en annens melding, skrive RT foran og så poste den på sin egen feed. Tanken er å spre det morsomme/interessante budskapet fra en du selv følger med på til dine tilhengere, slik at de får ta del i morroa. Problemet er at mange følger de samme menneskene, og det kan fort bli veldig mye retweets og lite original informasjon. Dette var lenge kun en konvensjon - Twitter har heldigvis begynt å anerkjenne det som en protokoll, og gitt deg muligheten til å se bort ifra retweets du mottar. Dette innebærer likevel duplisering av informasjon i stor skala.
Søppelpost!
Søker du etter informasjon om et produkt finner du masse, masse info - gjerne fra folk som vil selge det til deg, for en billig penge, og ikke mennesker som har brukt det og ytrer sin personlige mening. Spam-aspektet er også veldig tydelig i form av falske brukerkontoer, som opprettes kun for å spre reklame og gjerne abonnerer på dine poster (i håp om at du skal gjengjelde tjenesten og øke reklamens troverdighet.)
140 tegn
Det er dessverre mye som kan sies langt bedre på 250 tegn enn på 140 tegn. En tweeter må ofte kappe, slipe, knuse, komprimere og tråkke på budskapet for å få plass til det i én melding. Den beste løsningen er ofte å kutte ned på informasjonen - si mindre, men si det på en bedre måte. Personlig synes jeg denne grensen burde vært mer fleksibel - Facebook illustrer at det slett ikke er problematisk at brukerne kan få styre dette mer selv. Opphavet til 140-tegnsgrensen er teknisk - meldingene skulle passe inn i en tekstmelding.
Funksjonalitet? Hvilken funksjonalitet?
La oss ta et par eksempler. Twitter har kun to typer meldinger - en standard tweet og (føyd til forholdsvis nylig) retweeten. Når brukere fører direkte samtaler med hverandre henger ikke tweetene sammen på noe vis, og en samtale mellom to forskjellige personer jeg abonnerer på kan fort okkupere en stor del av statusoppdateringene jeg får fra Twitter.
Det er heller ikke noen mekanisme for å ytre deg om noens oppdatering uten å poste noe selv. Facebook har støtte for begge disse use casene - samtaler mellom to eller flere er faktisk gruppert i samtaler, og du kan trykke "Like" på poster du liker. "Like" gjør det mulig å vise at du har sett en post og synes om den med minimal innsats, og lar posteren vite at noen setter pris på aktiviteten.
En god del av funksjonaliteten Twitter mangler kan legges til ved hjelp av tredjepartsprogrammer, men dette gjør ikke jobben for mannen i gata hvis Facebook har alt innebygd og lett tilgjengelig.
Brukes til alt - av alle
Reklame. Nyheter. Personlig informasjon du helst ikke vil høre. Jobb-skryt du kunne klart deg foruten. Vitser. Tragedier. Alt sammen i 140-tegns informasjonsdæsjer. Ikke overraskende er resultatet kaotisk og håpløst ustrukturert
Hyperaktive brukere og bestemor lever i samme binge
Noen av twitrerne jeg setter mest pris på poster et par ganger i uka. Samtidig følger jeg brukere som spytter ut 20 tweets om dagen. Ikke overraskende drukner mine ettertenksomme venner ofte i all støyen fra de hyperaktive. For en ukes tid siden måtte jeg gi opp en av twitrerne jeg fulgte - det kom riktignok en skikkelig godbit omtrent hvert femtente tweet, men alt innimellom var støy, og det var ikke verdt det i lengden.
Konklusjon: Et unikt rot
Twitter et rot. Det er masse duplisert informasjon, og funksjonalitet er det lite av. Til personlig bruk (les: kommunikasjon med venner) har Facebook fullstendig overlegen funksjonalitet, og pakker dessuten statusoppdateringene inn i en helhetspakke Twitter er sjanseløs mot.
På jobben bruker en del av oss Yammer, en lukket og langt mer komplett tjeneste. Den kopierer funksjonaliteten fra Facebook, har noen godbiter i tillegg og er sperret, slik at den er mer egnet for internkommunikasjon.
Twitter har dog sin egen sjarm. Tjenesten er helt åpen og har brukere i bøttevis; alle er på Twitter. Jeg bruker Yammer til jobb, Facebook til venner, og Twitter når jeg vil si noe til verden. Åpenheten og den enorme variasjonen i brukere og bruksområder gjør Twitter til en slags standardprotokoll for hurtig kommunikasjon på nett, og gjør at jeg vil fortsette som bruker i internett-overskuelig fremtid.
Viktige trender i 2010
Nå har vi lagt 2009 bak oss og gjør det beste vi kan for å komme tilbake til hverdagen etter en god julefeire. Starten på året brukes av mange til å legge nye planer og finpusse på sine strategier. I denne bloggen vil jeg trekke frem noen trender og temaer jeg mener vil være viktige i 2010 og som kan være til inspirasjon for deres virksomhet.
1. Cloud Computing
Dette var utvilsomt fjorårets heteste teknologitema, og vil trolig bli det i år også. Cloud Computing er fortsatt et område som er noe umodent og som mangler de helt store suksesshistoriene her i Norge. Jeg tror at mange virksomheter vil bruke 2010 til å eksperimentere teknisk med Cloud Computing. Samtidig er det viktig at organisasjonens forretningsmessige forståelse for dette området styrkes.
Som jeg har kommentert tidligere handler ikke Cloud Computing om teknologi, men om hvordan din organisasjon kan utnytte den leveransehurtighet og fleksibiliteten som denne forretningsmodellen kan tilby.
2. Sosiale medier
Oppmerksomheten rundt sosiale medier eksploderte sist år, godt hjulpet av valget i USA (og kanskje vårt eget). Mest oppmerksomhet i media fikk trolig nykommeren Twitter. Men tross oppmerksomheten havner Twitter på en beskjeden 23. plass på Norges mest populære nettsider, mens storebror Facebook kommer på en solid 2. plass, kun slått av Google. Dette bekrefter den meget tydelige trenden vi har sett at sosiale medier har inntatt vårt dagligliv og ikke bare er noe fjortisene driver med.
Utfordringen for virksomheter i 2010 er å definere hvordan de skal forholde seg til disse nye mediene. Noen vil trolig legge ned forbud mot bruk av denne typen nettsteder på arbeidsplassen, mens andre vil se mulighetene sosiale medier bringer med seg og vil hjelpe sine ansatte til å utnytte dette til noe positivt.
3. Open Source
Godt hjulpet av blant annet FriProg har Open Source kommet høyt opp på agendaen både i offentlig og privat sektor i de siste årene. Det er ikke lenger et spørsmål om man skal bruke Open Source, men hvordan. I dag finnes det Open Source-løsninger for alle deler av en IT-portefølje, da av noen ulik modenhet.
Jeg mener det kun er et tidsspørsmål før store virksomheter kan nyttegjøre seg av kun Open Source-løsninger. Det som er viktig når man beveger seg inn i den retningen er å se på hvordan man forvalter livsløpet til denne typen løsninger og da spesielt hvordan man får nødvendig support.
4. Smidighet
For at man skal kunne utnytte de tre overstående trendene, må man ha en organisasjon som kan reagere og handle hurtig. Organisatorisk smidighet er spesielt viktig for å kunne utnytte de forretningsmulighetene som Cloud Computing kan gi. Innen programvareutvikling er dette er kjent begrep, godt ledet an av metoder som Scrum og XP, mens det for bedriftsledere nok er et noe ullent tema.
Jeg tror en fornuftig aktivitet i 2010 vil være å sette seg inn metoder for å implementere smidighet høyere opp i organisasjonen og da kan Lean (best kjent fra The Toyota Way) eller Jugaad (nytt begrep fra India) være en god plass å starte.
5. Software Craftsmanship
Det er en ny bevegelse innenfor programvareutvikling, og den kalles for Software Craftsmanship. Smidig-bevegelsen sier ingenting om hva som forventes av oss som programvareutviklere; det handler om menneske, prosesser og holdninger. Software Craftsmanship går ut på å heve standarden på arbeidet som blir utført av programvareutviklere. Kort oppsummert: Det holder ikke å bare levere fungerende programvare innen tidsfristen, men kildekoden må være av høy kvalitet.
Smidig utvikling har i løpet av relativt kort tid etablert som ny beste praksis innenfor programvareutvikling og det er mye som tyder på at man nå er på toppen av hypen. Men smidig fokuserer lite på hvordan programvareutviklere jobber og selv om alle er smidige, kan man fortsatt lage dårlig kode som er vanskelig å endre og vedlikeholde. Jeg tror at vi i 2010 vil se økt fokus på Software Craftsmanship, spesielt siden det kan virke komplimenterende til smidig.
6. Tablet/lesebrett
Amazon har gjort Kindle tilgjengelig over hele verden, og i desember rapporterte Amazon om at de hadde solgt flere e-bøker enn papirbøker. Apple kommer til å lansere en egen tablet: iSlate. Jeg tror at disse aktørene i samarbeid med mediebransjen kan få til en god distribusjon av elektronisk innhold.
Vi kommer sikkert også til å oppleve og ta i bruk mange nye applikasjoner som gjør informasjon tilgengelig eller delbar. Utviklingsmiljøet på Apple-platformen har blitt veldig stort på grunn av iPhone, og det er grunn til å tro at denne utviklingen bare vil gå raskere og raskere. Vil 2010 bli året da næringslivet begynte å tenke på hvordan de kan dra nytte av en slik enhet?
Hvor smidig kan du bli?
”Plans are worthless. Planning is essential.”
- Dwight D. Eisenhower, general og president (1890-1961)
Dette sitatet gjelder mer enn noen gang nå når det er større og større etterspørsel etter å kjøre prosjekter etter smidige teknikker. Dessverre er det noen misoppfattelser om at smidig betyr at man ikke trenger å planlegge, og av den grunn kan det være fornuftig å spørre: Hvor smidig kan du egentlig bli i prosjektene før det går utover kontroll? Er smidig på vei til å ta fullstendig over for mer tradisjonelle prosjektmetodikker, eller vil en kombinasjonsmodell vokse frem?
Det er alltid behov for målbilder
Min erfaring sier at det ofte er vrient å benytte smidig fullt ut i de store utviklingsprosjektene. I slike prosjekter har man behov for målbilder, både funksjonelle og tekniske, som viser hva man ”sikter mot”. Utarbeidelsen av målbildene vil kreve at man arbeider med design, løsningsbeskrivelse og planlegging av løsningen i forkant, og dermed tar en del valg tidligere i prosessen enn det smidig legger opp til.
Dette betyr ikke at man må gjøre et rent fossefall hvor man detaljdesigner systemet i forkant av konstruksjon, men heller gjør som jeg snakket om i mitt innlegg om ”smidig migrering”. Der nevner jeg at man kan, i en fase før konstruksjonsfasen, lage en løsningsbeskrivelse som kun beskriver det man trenger for å kunne starte konstruksjon og videreforedle denne beskrivelsen i konstruksjonsfasen. På denne måten vil man unngå å ta for mange avgjørelser for tidlig, og kanskje på feil grunnlag. Man vil kunne styre løsningen i prosjektet inn på en vei som leder til at man når sine målbilder, i tillegg til å ta et bevisst valg for når det absolutt siste tidspunkt for å ta avgjørelsen er.
Videre bør man ha en mekanisme for å endre målbildene etter hvert som prosjektet skrider frem. Dette kan gjøres ved hyppige workshops i konstruksjonsfasen, hvor man ser på hva man skal implementere i de kommende iterasjonene.
Prosessene i store prosjekter kan gjøres smidige
Selv om man i store prosjekter kanskje ikke vil kunne kjøre smidig fullt ut, vil man ved relativt enkle grep kunne gjøre prosessene i store utviklingsprosjekter smidigere. Teknikker som par-programmering, testdrevet utvikling, kortere leveranseperioder og mer integrasjon av representanter fra forretningssiden i scrumteamene blir mer og mer utbredt. Dette gjør prosessene mer smidig.
Kombinasjonsmodellen
Så; vil smidig kunne ta fullstendig over for tradisjonelle teknikker? Både ja og nei, og kanskje er det mest funksjonelle en kombinasjonsmodell. Det er et meget stort steg å gå fra tradisjonelle metoder, som for eksempel fossefall, og til en fullblods smidig modell hvor forretningssiden og IT jobber smidig sammen. I mindre prosjekter vil det nok kunne være lettere å kjøre fullblods smidig. Da det er et begrenset sett med personer involvert, som enklere vil kunne ha full kontroll enn i virkelig store prosjekter. Her vil en kombinasjonsmodell med utarbeidelse av målbilder og smidige prosesser innenfor tradisjonelle rammer være det mest funksjonelle.
Jeg har ikke satt noen faste rammer for hvor smidig man man kan bli før man mister litt kontroll i store prosjekter, men vil gjerne ha en debatt om tema. Med andre ord: Kjør debatt ;-)
Erfaringer med Cloud Computing – Det handler ikke om teknologi
Denne høsten har jeg jobbet mye med Coud Computing - gjennom samtaler med kunder, i ulike foredrag, og i samarbeid med kolleger fra hele verden. Vi har sett på hvilke forretningsmuligheter skyen tilbyr. Dette arbeidet har vært utrolig inspirerende og lærerikt, og jeg ønsker å dele noen av mine erfaringer gjennom en serie blogger fremover. Nedenfor ser du en presentasjon som dekker de temaene jeg kommer til å skrive om fremover. Bruk det gjerne videre! I denne første bloggen vi jeg vise hvorfor Cloud er viktig for deg og din virksomhet gjennom å se på forretningsdrivere.
CloudComputing - The future is in the sky
Det handler ikke om teknologi
Jeg bruker alltid å starte foredrag og samtaler med kunder med at Cloud Computing ikke handler om teknologi, men det er en ny måte å drive din virksomhet på. Jeg fokuserer på 5 forretningsdrivere som er viktige for mange virksomheter og hvor Cloud Computing kan være et meget godt virkemiddel.
- Kostnadsreduksjon: Ved bruk av Cloud Computing betaler du for det du bruker og ikke for et mulig framtidig behov. En annen faktor til kostnadsreduksjon er at din virksomhet har mulighet til kjøpe tjenester fra hele verden - fra der de til enhver tid er billigst.
- Unngå kapitalkostnad: Med en prismodell hvor man betaler for bruk (pay as you go) kan din virksomhet flytte IT-utgifter fra kapitalkostnad til operasjonell kostnad. Dette er spesielt interessant i disse finanskrisetider og kan gi mulighet for starte nye prosjekter selv i dårlige tider.
- Leveransehurtighet: Tiden det tar å levere verdi reduseres kraftig. Har man et forretningsbehov, for eksempel et behov for en server, kan man kjøpe dette som en tjeneste Amazon WS og typisk redusere tiden fra bestilling til levering fra 4 uker til 4 minutter.
- Fleksibilitet: Tjenester levert gjennom skyen har tilsynelatende en utømmelig ressurs. Dette gir din virksomhet mulighet til å velge kun de tjenester du til enhver tid trenger, og gir fleksibilitet å skalere opp (og ikke minst ned) etter behov, uten å allokere dyr og unødvendig kapasitet i forkant.
- Grønn IT: Selv om det er et litt omstridt tema, så er Grønn IT viktig og det kan i fremtiden bli stilt strenge krav ved offentlige anskaffelser. En av de viktigste faktorene for Grønn IT er utnyttelse av datakraften på dine servere. Generelt sett er kapasitetsutnyttelsen og energieffektivitet bedre i store datasentre som leverer tjenester gjennom skyen og ved å bruke disse tjenestene kan din virksomhet få et lavere karbonfotavtrykk.
Min erfaring gjennom er at disse forretningsdriverne er relevante for både offentlig og private virksomheter og at de danner et godt utgangspunkt for å starte en samtale om hvordan Cloud Computing kan hjelpe. I neste blogg vil jeg dele mine erfaringer og tanker om hvor man skal begynne hvis man ønsker å forfølge denne muligheten.
Møt oss på Smidig 2009!
Smidig 2009 avholdes 22. og 23. oktober ved Oslo kongressenter. Vi har meget aktive fagmiljøer i Capgemini, og ser frem til å bidra til årets arrangement. Vi stiller sterkt med til sammen seks lyntaler på konferansen:
Skjermbildeprototyping: En naturlig del av ethvert smidig utviklingsprosjekt? (Video)
Foredragsholder: Jonas Follesø
For å oppnå smidighet i våre utviklingsprosjekter benytter vi oss av smidige prosjekt- og utviklingsprosesser. Vi benytter utviklingsteknikker som Test Dreven Utvikling (TDD) og kontinuerlig integrasjon (CI). Men hva kan vi gjøre for å bli mer smidige i måten vi designer brukergrensesnittet i applikasjonen vår? Skjermbildeprototyping er en effektiv og billig måte å prøve ut ideer for brukeropplevelsen i en applikasjon. Ved å ikke implementere brukeropplevelsen fra kode kan vi ta oss råd til flere iterasjoner og være sikker på at vi finner den riktige brukeropplevelsen for sluttbrukeren. Lyntalen vil presentere noen eksempler på "digitale papirprototyper" laget i verktøyet Balsamiq, og vise hvordan vi kan gjøre skjermbildene om til en interaktiv prototyp i SketchFlow.
Produktive utviklere: Presenter gevær! (Video)
Foredragsholdere: Truls Jørgensen og Jan-Erik Carlsen
Hvorfor bryr ikke Windows-brukere seg om effektivitet? Som utvikler er du en ekspertbruker av ditt EDB-verktøy. Likevel finner du deg selv sittende og klikke deg gjennom endeløse trestrukturer gang på gang. Du lar deg forstyrre av popup-ballonger som minner deg om de fire trådløse nettverkene i nærheten som du ikke trenger, at du har ubrukte ikoner på desktopen, eller at du har fått ny spam i mailboksen fra byggserveren. Vi har bedt verden om hjelp til å samle en godtepose med gratis verktøy for å øke utvikleres produktivitet. Lyntalen vil presentere verktøyene vi har tatt med i denne samlingen og hvordan disse kan hjelpe deg til å jobbe mer effektivt.
Behavior-Driven Development, steg 1: Ikke tenk som en utvikler! (Video)
Foredragsholder: Jan Fredrik Stoveland
Tester først, ja vel. Men hvor havner koden når testene styrer deg i gal retning? Utviklere har en tendens til å enten la seg forlede av den tekniske forståelsen av koden eller dikteres av testbetingelser når de funksjonelle enhetstestene skrives. Dette forenkler ofte utviklerens oppgave med å skrive og kjøre testene, men gir det en fullgod test av den funksjonaliteten som brukeren etterspør? Denne lyntalen presenterer noen gode og smidige prinsipper rundt bruk av Behavior-Driven Development (BDD) som kan få testene på rett kjøl og koden på riktig vei fra starten, basert på erfaringer fra et stort offentlig IT-prosjekt - NAV Pensjonsprogrammet.
Scrum kan forpeste utviklernes hverdag! (Video)
Foredragsholder: Mads Aaagard
Denne lyntalen fokuserer på de negative effektene Scrum kan fremprovosere i utviklernes hverdag. Mennesker er veldig forskjellige, og det er en fin balansegang mellom effektive, veldrevne prosjekter og prosjekter med mye stress og frustrasjon. Ulike implementeringer av Scrum har ulik påvirkning på utviklerne. Scrum er mer enn bare fremdrift og burndowns. Trivsel over tid er også viktig for at Scrum skal fungere. Håpet er at de som hører på vil reflektere litt over hvordan deres egne implementeringer av Scrum kan påvirke utviklerne.
Brett opp ermene og sloss! (Video)
Foredragsholder: Tommy Ryen
Hva skjer hvis man som utvikler finner en logisk brist midt i hjertet av domene- og datamodellen, og produksjonsdato nærmer seg fortere enn man setter pris på? Ny funksjonalitet vil kreve et meget kreativt stykke kode for i det hele tatt å passe inn i eksisterende løsning. I en slik situasjon finnes det ofte en løsning som ikke bare fikser problemet, men også et par-tre andre kjappe løsninger som har blitt laget, men som er en større omstrukturering av koden. I horisonten venter derfor noe som minner om en 20 runders tittelkamp i bokseringen for å få igjennom endringen. Så hva gjør man? Hvordan går man frem? Hvem må overbevises? Finnes det en øvre pris for et godt domene?
Daily Scrum – Et verktøy for kontinuerlig læring og kunnskapsdeling
Foredragsholdere: Robert Ofstad og Jon-Kristian Slettebø
På hvilken måte kan en god daily scrum bidra til kontinuerlig prosessforbedring? Vi hører ofte om utviklere og team som føler daily scrum som en sekk trædd over hodet, eller som kjedelig, stressende og at det fører til at man må stå til rette for hverandre. Behøver det være slik? På NAV pensjonsprosjektet har vi hatt stor suksess med implementeringen av daily scrum som et verktøy for å fremme både læring, kunnskapsdeling, prosessforbedring og som en arena for å løfte problemstillinger. Denne lyntalen vil ta for seg noen av grepene vi har gjort for å utnytte daily scrum maksimalt på et prosjekt som ikke er omgitt av smidige rammer.
Vi håper å se dere på Smidig2009!
Jan-Erik Carlsen og Truls Jørgensen er 2 av foredragsholderne på Smidig og har ferdigstilt dette sammendraget.
Skjermbildeprototyping – en nyttig teknikk i smidige prosjekter
Smidige utviklingsprosjekter
For meg handler smidige utviklingsprosjekter om å gi kunden maksimal verdi fra programvaren som utvikles gjennom å oppfordre til- og ta imot endringsønsker etter hvert som kundens og utviklingsteamets forståelse av programvaren endrer seg. For å oppnå smidighet til og raskt legge til ny, eller endre eksisterende funksjonalitet, benytter vi oss av smidige metodikker som XP, Scrum eller Lean. Smidige metoder hjelper oss å organisere og prioritere oppgavene som skal løses, håndtere endringsønsker, planlegge iterasjoner og bygge inn kontrollpunkter hvor kunden får demonstrert programvaren som utvikles. For å oppnå nødvendig endringsevne i koden benyttes ofte teknikker som testdrevet utvikling. Men hva kan vi gjøre for å bli mer smidig i måten vi jobber med brukeropplevelse?
Smidig utvikling av brukeropplevelse
Brukeropplevelse er et vidt begrep som blant annet omfatter skjermbildestruktur, hjelpetekster, bruk av bilder og symboler, responstid, animasjoner, interaksjon mellom elementer og skjermbilder, og det grafiske uttrykket til applikasjonen.
I dag er brukeropplevelse ofte en nedprioritert del av utviklingsprosjekter. Kunden uttrykker ofte ønsker om at programvaren skal være brukervennlig og se bra ut, uten å sette målbare krav for om dette oppnås. Sjelden benytter vi oss av interaksjonsdesignere, grafiske designere eller eksperter på brukskvalitet. Brukeropplevelsen blir det som regel opp til utviklerne å realisere etter beste evne. Som regel betyr dette at man går rett i gang med implementering av skjermbildene i kode. Enten som HTML og CSS om man bygger en webapplikasjon, XAML og Flash om man lager en rik internettapplikasjon, eller C# og Java om man bygger en desktop-applikasjon. Ved slutten av en iterasjon demonstreres funksjonaliteten som er implementert og kunden får mulighet til å komme med tilbakemeldinger. Erfaringer fra slike demonstrasjoner er ofte at kunden henger seg opp i uviktige detaljer som at en knapp må 25px til venstre, eller at tittelen må være ”større og blåere”. Sjelden får vi mer fundamentale tilbakemeldinger om omorganisering av skjermbildestruktur, navigasjonsstruktur eller hvordan brukeren løser en oppgave i et skjermbilde. Så lenge det fungerer, og tittelen er stor og blå, er kunden fornøyd.
Om tilbakemeldingene skulle gå på større omstruktureringer av brukeropplevelsen i applikasjonen er ofte utviklerne lite villige til å gjøre dette. De har tross alt lagt ned mye arbeid i å implementere løsningen. Brukergrensesnittkode er ofte vanskeligere å endre siden vi som regel ikke har samme testdekning eller refaktoreringsstøtte som for forretningslogikken.
Papirprototyper
En mye brukt teknikk fra brukskvalitet fagfeltet er papirprototyper. Teknikken går ut på å lage enkle papirprototyper av skjermbildene som skal lages. Skjermbildene kan testes ut på brukere som blir bedt om å utføre oppgaver. Flyten mellom bildene ”styres” manuelt ved at man bytter ut arkene etter hvert som brukeren forsøker løse oppgaven. På denne måten kan man identifisere svakheter i designet og prøve ut nye ideer. Siden kosten av å lage nye forslag og prototyper er ekstremt lav kan vi forkaste ideer som ikke fungerer.
Om du ikke ønsker å tegne prototypene for hånd har det den siste tiden kommet flere gode verktøy som baserer seg på de samme prinsippene som papirprototyping. Et utmerket eksempel på dette er Balsamiq. Ved hjelp av et stort bibliotek håndtegnede komponenter kan du sette sammen en skjermbildeprototype i løpet av minutter. Ved å begynne arbeidet med brukeropplevelsen i et verktøy som Balsamiq kan du få viktige tilbakemeldinger fra kunden mye tidligere, samtidig som du kan lage flere alternativer enn om du begynner å lage skjermbildene direkte i kode. Det håndtegnede utseende på prototypene gjør at kunden ikke tror dette er det endelige designet, men en prototype som kan forkastes uten at mye arbeid går tapt.
Fra statiske skjermbilder til interaktiv prototype
Statiske skjermbilder er ikke alltid nok til å teste brukeropplevelsen i en applikasjon. For å virkelig kunne prøve ut ideer trenger vi interaktive prototyper. Her finnes det også verktøy som kan være til stor hjelp. Nylig lanserte Microsoft verktøyet SketchFlow. Som navnet tilsier er dette er verktøy som lar deg prototype flyten mellom skjermbildeskissene dine. I SketchFlow kan man importere skannede papirprototyper eller importere prototypene man har tegnet i Balsamiq eller andre verktøy. Deretter kan man tegne opp et skjermbildekart som kobler sammen de forskjellige skjermbildene i applikasjonen. På hvert skjermbilde kan man legge inn animasjoner eller andre former for interaktivitet som viser hvordan den endelige applikasjonen kan fungere.
For noen deler av applikasjonen kan det være nødvendig å lage en mer komplett funksjonell prototype. Siden SketchFlow baserer seg på Silverlight 3 kan man kan raskt gjøre om enkeltskjermbilder til en interaktiv applikasjon. Her kan man bruke vanlig C# programmering til å virkelig illustrere hvordan den endelige applikasjonen kan oppføre seg.
Når prototypen er ferdig kan den eksporteres som en webapplikasjon og gjøres tilgjengelig for kunden. SketchFlow har innebygget funksjonalitet for å samle inn tilbakemeldinger i form av kommentarer eller tegninger og markeringer dirrekte på skjermbildene. På denne måten kan vi samle inn viktige tilbakemeldinger før vi begynner implementeringen av den endelige applikasjonen.
Oppsummering
For å oppnå størst mulig effekt i smidige prosjekter må vi hele tiden se på hva vi kan forbedre. Jeg tror vi kan lære mye fra andre fagområder som brukskvalitet og interaksjonsdesign. Bruken av prototyper, enten på papir eller på skjerm, er et eksempel på noe som kan gi stort gevinst i smidige utviklingsprosjekter til en lav pris. Vi kan involvere kunden tidligere og tettere i design av brukeropplevelsen. Vi kan kjøre kortere iterasjoner siden nye skjermbilder lages i løpet av minutter, noe som fører til større smidighet i måten vi jobber med brukeropplevelsen av applikasjonen som utvikles.
Har du lyst å lære mer om skjermbildeprototyping, Balsamiq og SketchFlow? I så fall håper jeg å treffe deg på Smidig 2009 konferansen 22-23 oktober i Oslo. Her vil jeg holde en lyntale om skjermbildeprototyping i smidige prosjekter.
Twitter og Yammer revolusjonerer arbeidet
På søndag var det et intervju med meg og to av mine kollegaer i Aftenposten om hvordan vi bruker sosiale medier i jobbsammenheng. Vi har fått mange tilbakemeldinger på innholdet i artikkelen - noen gode, og noen mer kritiske. To innvendinger har vært at artikkelen var noe tynn og at dette kan minne om keiserens nye klær. Det er alltid morsomt med gode tilbakemeldinger, men det er først når man blir utfordret med konstruktiv kritikk at man prøver å se om det er noe som kan forbedres. Og siden vi lever i en Web2.0-verden kan jeg bruke bloggen til å utdype noen av utsagnene i artikkelen.
Keiserens nye klær
Jeg kan forstå at mange er skeptiske nyvinninger som Twitter og Yammer. Andre mener at disse nye sosiale mediene ikke representerer noe nytt. Verktøy som ICQ og Mirc dominerte tidligere på gutterommet og mange vil hevde at Twitter og Yammer er gammel teknologi. Dette kan jeg tildels være enig i, siden det fortsatt dreiser seg om å bruke digitale verktøy til å sende en form for meldinger mellom en eller flere parter. Men det som er så forskjellig i dag er hvordan vi bruker det - vi har endret atferd!
Filmen Us Now gir noen meget spennende eksempler bruk av sosiale medier og har virkelig fått meg til å innse hvilken kraft som ligger i disse nye verktøyene. Første del av filmen (1m 20sek) avsluttes med et utsagn fra Clay Shirky som har inspirert meg og mange andre:Revolution doesn’t happen when the society adopts new tools, it happens when society adapts new behaviours
Dette betyr det er ikke verktøy som Twitter og Yammer som i seg selv kommer til å revolusjonere arbeidet vårt, men det er hvordan vi bruker det. Vi må endre måten å tenke på, og har muligheten til å åpne opp for tanker og inspirasjon fra omverden, dele, kommentere og bygge på andres ideer, også utenfor våre organisatoriske grenser. Er dette keiserens nye klær - nei! For da Keiseren ble lurt av et par slue rådgivere, hører vi i dag på den gutten som avslører hele opplegget, og han gjør det via Twitter.
Sosiale medier er det som vil få oss ut av finanskrisen
Er dette virkelig nok til å få oss ut av finanskrisen, eller blir den for tynn? Jeg tror at det absolutt er verdt å utforske muligheten og se om det finnes noe som kan gjøre oss mer effektive. Nye arbeidsformer, hjulpet av innovativ teknologi, bidrar til dette. I lengden er det de bedriftene som ikke er redde for å adoptere nye løsninger og endre måten de arbeider på, som vil vinne.
Også Business Intelligence - løsninger krever kost-nytte analyse
I følge en ny undersøkelse fra IBM uttaler åtte av ti it-sjefer at de "best kan bedre konkurransedyktigheten gjennom teknologi for analyse og business intelligence". De nordiske it-sjefene skal være enige med resten av verden om dette.
"Så bra!" tenkte jeg først. Endelig har de forstått det. Men etter å ha tenkt meg om slo det meg; Men mener forretningssiden det samme? Hva med CFOene og CEOene? Er det ikke de som burde si dette, og ikke it-sjefene?
BI er nok fremdeles en "IT-greie" veldig mange steder, og ikke noe forretningssiden har et bevisst forhold til. For hva er egentlig business caset for BI? BI er ikke først og fremt for å øke effektiviteten eller spare kostnader, og dermed blir kost/nytte-verdien lett veldig ullen. For hva er egentlig verdien av bedre beslutninger eller økt innsikt? Hvordan skaper man et business case for BI?
Og dette var akkurat temaet på mitt foredrag på beslutningsstøttedagen nå i september.
Jeg mener det er tre momenter som er ekstremt viktig å kommunisere til forretningssiden for å sikre investeringsvilje og engasjement:
- Informasjon har en høy verdi i seg selv, og mangelfull håndtering av informasjon koster bedriften mye penger.
- Informasjon blir stadig viktigere, og vil i fremtiden bli kanskje det viktigste konkurransefortrinnet for å overleve i et stadig tøffere marked
- BI er metoden for å utnytte informasjon optimalt, og man kan vise en sammenheng mellom BI og oppfyllelse av virksomhetens viktigste målsetninger.
Første punkt var tema i et mine tidligere innlegg, andre punkt vil jeg sikkert komme tilbake til en annen gang, men tredje punkt er ofte det som sitter lengst inne og som jeg vil si litt mer om her og nå. Det er som ofte vanskelig å lage et økonomisk business case for BI, men det er andre måter å synliggjøre verdi på. Det som må gjøres er å rasjonalisere verdien til BI
- Du må finne den logiske sammenhengen mellom virksomhetens visjon, strategi og mål, og BI
- Du må finne den logiske sammenhengen mellom de forretningsmessig utfordringer og problemer virksomheten har i dag, og BI
- Du må finne den logiske sammenhengen mellom de forretningsmessige muligheter man ser fremover, endrede rammebetingelser og endring i kundenes krav, og BI
- Du må kunne peke på konkrete beslutninger og prosesser som kunne vært bedre og mer effektive med BI.
Ved å stille de riktige spørsmålene, ved å vise sammenhengen, ved å ta tak i de reelle utfordringene (i stedet for å kun fokusere på "hvilken rapport trenger du?"), så bygger du faktisk et business case og minst like viktig; du skaper engasjement og tro på nytteverdien til datavarehuset.
"Men er ikke dette en teknologi-blogg da?" spør du kanskje. Joda, men pr. idag er alt for mange investeringer preget av kortsiktighet og siloløsninger som ofte skyldes at IT mangler evnen til å formidle en mer visjonær og helhetlig løsning på en forståelig måte til forretningssiden.
Jeg tror derfor at en av de fremtidige it-ansattes viktigste egenskap blir å kunne formidle verdien av det de gjør på en forståelig måte til de som faktisk har nytte av den.
Migrering med en touch av smidig
Migreringsprosjekter kan by på mange utfordringer da man skal fase ut et eller flere systemer,og erstatte det gamle med noe nytt. Utfordringer som dårlig datakvalitet fra det gamle systemet, hvordan man skal få med seg all funksjonalitet og hvordan man kan la de gamle og nye systemene leve ved siden av hverandre er kjente problemstillinger. Alt dette må man ta hensyn og planlegge med i et migreringsprosjekt. I dette innlegget vil jeg oppsummere mine erfaringer, og gi deg noen hint på vegen.
Først ønsker jeg å definere noen hoved-elementer i et migreringsprosjekt
- ”Overordnet produktkø”. En kø som inneholder epics eller brukerhistorier som gjenspeiler det totale funksjonelle målbildet for systemet som skal utvikles. Er det snakk om migrering må med andre ord køen minimum inneholde brukerhistorier som dekker funksjonaliteten i det gamle systemet.
- ”AS-IS bildet” forteller deg noe om hvordan systemporteføljen din ser ut nå. Dette er et viktig bilde da det forteller deg noe om avhengighetene i det gamle systemet, og dermed noe om rekkefølgen du kan fase ut systemmoduler på.
- ”TO-BE bildet” forteller deg hvordan porteføljen skal se ut etter migreringen. Ofte er dette bildet lagt utover leveranser, hvor bildene viser hvilke systemmoduler du har i nytt og gammelt system til en gitt tid, og hvilken funksjonalitet de støtter.
- Migreringsstrategien viser hvordan du har tenkt å håndtere at du skal skifte ut et system. Skal du gjøre hele migreringen på en gang, eller skal du la systemene leve ved siden av hverandre? Det kan godt hende at det nye systemet må benytte moduler i det gamle og visa versa en periode dersom du velger det siste.
- Migreringsplanen er veien du må gå fra AS-IS til TO-BE, med andre ord en plan som gjenspeiler migreringsstrategien og den overordnede produktkøen. Planen må vise hvor mange leveranser du har tenkt å bruke på å levere produktkøen, og hvilke kø-elementer som tilhører en gitt leveranse. Videre må den vise hvilke deler av det gamle systemet som erstattes av det nye i hver leveranse.
Veien fra ”overordnet produktkø” til noe et team kan konstruere
Forretningssiden og arkitekter hos kunden er de som bør utarbeide den overordnede produktkøen. Køen må prioriteres, elementer grupperes etter funksjonalitet og du bør sette relative vekter på elementene slik at du har en måling på størrelse (benytt gjerne planning poker til dette). Når køen er på plass må du gjøre et stykke arbeid for å sikre komplettheten i køen. En måte å gjøre dette på er å mappe kø-elementer opp til moduler i det gamle systemet, noe som vil kunne sikre at du har dekt all funksjonalitet i det gamle systemet i køen. Er det nye systemet prosessdrevet (for eksempel et system for saksbehandling) kan du og forsøke å mappe kø-elementene opp mot prosessene det nye systemet skal dekke for å sikre at du dekker all funksjonalitet saksbehandlerne trenger. Når du da har en komplett overordnet produktkø må du komme deg til leveranser, og videre til noe scrum-teamene dine kan ta tak i.
Følgende punkter kan følges for å komme fra en overordnet produktkø til en kø som et scrum-team kan starte å jobbe på
- Produkteiere og hovedarkitekter bestemmer hvilke elementer i den prioriterte overordnede køen som leveres i hvilke leveranser. Dette kalles en leveransekø som må prioriteres slik at man alltid arbeider på de brukerhistoriene som er av høyest prioritet. Migreringsstrategien og ”AS-IS” bildet gir input her, da utfasing av et element i det gamle systemet kan kreve at du leverer flere moduler enn 1:1 mapping til en ny modul i det nye systemet. Dette pga avhengigheter mellom modulene i det gamle systemet. Kanskje kan de modulene i det gamle systemet som er avhengig av den som fases ut benytte den nye modulen i det gamle systemet i stedet?
- Teamarkitekter, arkitekter fra kunden og forretningsarkitekter løsningsbeskriver leveransekøen. Løsningsbeskrivelsen bør resultere i følgende artifakter
- Et overordnet design for leveransen. Ikke gå i stor detalj, men design nok til å ta bort store risiki.
- Detaljering av leveransekøen slik at elementene er på et nivå som kan tas inn til et team. Benytter du Atlassian Jira er subtask et bra element å benytte til detaljering.
Videre til kontruksjon
Når dette er gjort kan man ta elementene inn til konstruksjon. I denne fasen er det teamene som skal levere, og det er derfor viktig at de får forme løsningen. Smidig sier at man i hver iterasjon skal benytte en viss del av tiden, kanskje rundt 10%, til å se fremover på kommende iterasjoner. Benytt gjerne dette i workshops hvor teamarkitekter og de funksjonelle fra hvert team møtes for å
- Se i leveransekøen på hva som skal leveres de to neste iterasjonene
- Ta det overordnede designet fra løsningsbeskrivelsen, og detaljer det for de to kommende iterasjonene. Finner du da en skjult bombe, for eksempel to iterasjoner frem i tid har du litt tid på å løse problemet ved å gjøre noe i neste iterasjon.
Arbeidet i denne workshop kan timeboxes til 1 time med arbeid i hvert team, og 5 minutters presentasjon av arbeidet fra hver gruppe for de andre teamene. Dette bør hjelpe deg til å kartlegge eventuelle avhengigheter på tvers av teamene dine, og sørge for at arkitekter og funksjonelle ser totaliteten i det som leveres. I tillegg bør du sørge for å ha en ”feedback loop” som sikrer at feedback fra konstruksjon gjør at resultatet fra løsningsbeskrivelsen av neste leveranse blir litt bedre enn den forrige. Dvs. spør om teamene dine synes output fra løsningsbeskrivelsen var for detaljert, mangelfull etc.
Det siste jeg vil nevne er at den overordnede produktkøen din må være en levende og smidig kø. Etter hver leveranse i et migreringsprosjekt vil ”AS-IS” bildet endre seg, noe som kan endre prioritet i køen og/eller tilføre eller slette elementer i køen. I hver løsningsbeskrivelse kan det være en ide å løsningsbeskrive litt mer enn det du har kapasitet til, dette vil gjøre deg litt mindre sårbar for endringer i køen og sørge for at du har nok jobb når teamene virkelig får opp farten.
Lykke til ;-)
BPM - Støtteverktøy for prosessforbedring
Dette er en bloggserie om Business Process Management (BPM) og de ulike elementene som understøtter dette brede fagfeltet. I dette innlegget skal jeg introdusere noen av de teknologiske prosessverktøyene som støtter opp under fagfeltet
Verktøy for prosesshåndtering
Business Process Management drives av forretningssidens behov for prosessforbedring. Organisasjonen må kunne modellere og analysere prosessene slik at man kan identifisere forbedringstiltak. Den må også kunne sette prosessene sine "i drift" - altså i mange tilfeller vil dette bety en form for teknologisk eksekvering. Når så prosessene er aktive må de også kunne måles - slik at prosesseier kan iverksette forbedringstiltak. Forretningssiden driver endringsprosessen i organisasjonen, men den er sterkt understøttet av teknologi for å kunne realisere sine stadig endrede behov . I klassifiseringen av understøttende prosessverktøy har man tradisjonelt skilt mellom BPA (Business Process Analysis) verktøy og BPMS (Business Process Management Suites).
BPA verktøy har vært sentrert rundt forretningssiden, og har rik funksjonalitet for modellering, analyse, simulering og styring. Verktøyene har vært drevet av behovet for å kunne modellere/dokumentere forretningsprosessene, analysere, simulere, styre og forbedre disse. Eksekvering av prosessmodeller er holdt utenfor i de rene BPA verktøyene og håndteres gjennom organisasjonens eksekveringsplattform. De fleste av verktøyene kan eksportere ut prosessmodeller for viderebehandling på teknisk side, og noen har også dannet partnerskap mot leverandører på eksekveringssiden.
BPMS har en teknologisk bakgrunn hvor hovedfokus har vært eksekvering/automatisering av prosesser. Rundt denne kjernen har de blitt utvidet med støtte for modellering/analyse, forretningsregler, workflows og annen understøttende programvare. Problemstillingen her har vært at BPMSene har vært fokusert mot teknisk eksekvering, og de andre elementene i ”Suiten” har ikke fått nødvendig fokus og funksjonalitet. En del programvare har blitt ”brandet” som BPMS, på tross at det har vært lite fokus på ”Management” biten. Dermed har dette blitt et arbeidsverktøy for IT siden i organisasjonen, mens forretningsbrukere har benyttet egne verktøy som ikke synkroniseres med teknologisiden.
Konsoldiering av funksjonalitet
Som nevnt innledningsvis er BPM veldig ofte avhengig av underliggende teknologi. For å kunne drive den kontinuerlige forbedringssyklusen trenger man både analyse, design, simulering, eksekvering, måling, oppfølging, styring og andre understøttende elementer. Dette behovet gjør at BPA og BPMS verktøyene for prosesshåndtering drives mot hverandre og danner mer komplette støtteverktøy. BPA verktøyene trenger eksekveringskapabilitet og BPMSene må ta inn i seg områder/funksjonalitet som er kritiske for forretningssiden. De ledende leverandørene innenfor hver ”leir” kjøper opp/tilegner seg funksjonalitet for å komplettere sine produkter og sluttresultatet er nye allianser/produkter som bedre skal tjene både forretning og IT brukerne i organisasjonen. Hvis man ser på Gartners analyser av markedet ligger alt til rette for denne type konsolideringer. Eksemplevis kan man se på sommerens hendelser, hvor Software AG (WebMethods) kjøpte opp IDS Scheer (ARIS).
Lettere, billigere og mer tilgjengelig programvare
En annen trend knyttes til tilgjengeligheten og "tyngden" på programvaren - både teknisk og kostnadsmessig. Hittil har mange av verktøyene vært beregnet på en "lukket krets" med ekspert-brukere, med lisensiert tilgang til forholdsvis dyr og resurskrevende programvare. Disse har så distribuert innhold videre ut til organisasjonen.
Verktøyene begynner nå å bli "lettere" i sin form, f.eks Lombardi Blueprint og IBM Blueworkskjører via "nettskyen" og krever kun at nettleser er installert. ARIS har også kommet ut i en ”lettvekt-utgave”, ARIS Express. Alle disse verktøyene er gratis i sin standard form. Fremover betyr denne trenden at flere i organisasjonen vil ha tilgang til denne type verkøty, og via ”nettskyen” kan man jobbe både samarbeidsrettet og uten forhåndsinstallert programvare. Styringsmodellen for BPM, rolle og ansvarsfordeling vil selvfølgelig være utrolig viktig for å kunne utnytte denne muligheten på en riktig måte.
Fortsettelse følger
Dermed avsluttes dette innlegget, men BPM bloggserien lever videre. Neste gang planlegger jeg å ta opp spørsmål knyttet til notasjon i modelleringsammenheng.
Abonner
RSS feedSist publisert
- Hundreogførti tegn i rampelyset
- Viktige trender i 2010
- Hvor smidig kan du bli?
- Erfaringer med Cloud Computing – Det handler ikke om teknologi
- Møt oss på Smidig 2009!
- Skjermbildeprototyping – en nyttig teknikk i smidige prosjekter
- Twitter og Yammer revolusjonerer arbeidet
- Også Business Intelligence - løsninger krever kost-nytte analyse
- Migrering med en touch av smidig
- BPM - Støtteverktøy for prosessforbedring