Capgemini bidrar på Javazone – du treffer oss der!
Javazone 2010 arrangeres 8 – 9 september og Capgemini er å finne både med stand og på scenen. Capgemini sitt Java fagmiljø er aktivt og bidrar både ute hos våre kunder, samt i samlinger i fagmiljøet for å dele og styrke vår felles kompetanse. Under Javazone 2010 kan du besøke oss på vår stand eller høre noen av oss som jobber her gjennom disse foredragene.
Android 101 - Introduksjon til Android
Are Wold og Truls Jørgensen vil gi en introduksjon til utvikling på Android. Etter en kjapp gjennomgang av hva Androids er, og hva det IKKE er, går vi gjennom de mest sentrale konseptene i Android SDK. Disse konseptene danner basis for å forstå hvordan man utvikler applikasjoner enkelt og effektivt. Vi avslutter foredraget med å gå gjennom et praktisk eksempel på utvikling av en applikasjon som nyttiggjør seg flere av disse konseptene. Vi viser hvordan applikasjonen kan debugges, før vi går gjennom hvordan applikasjonssigneringsprosessen fungerer. Etter å ha demonstrert dette, slipper vi den på Android Market!
Anders Sveen vil i sitt foredrag snakke om integrasjon. På QCon tidligere i år lanserte Stefan Tilkov begrepet CSOA eller fullt ut: Common Sense Oriented Architecture. Det er på tide at vi slutter å forsøke å kjøpe oss ut av problemet med dyre, kompliserte løsninger og benytter intelligensen vår i stedet. "There is no silver bullet" skrev Fred Brooks i et paper i 1986 og siktet til at det ikke finnes noen teknologi som dramatisk vil forbedre effektivitet innenfor et tiår. Det virker som vi ofte vil tro på denne sølvkulen. Integrasjon er vanskelig. Og det hjelper ikke at vi forsøker å unngå problemet med produkter. Disse produktene kan gjøre ting litt enklere, men de gir også ekstra infrastruktur, bugs, ukjent software og lite transparens. Ved å holde seg til enkle prinsipper og rammeverk kommer man faktisk lenger på kort tid. I dette foredraget vil jeg ta for meg noen glemte fakta om integrasjon, og vise hvordan man kan bruke abstraksjon og enkle rammeverk for å gjøre integrasjon på en god måte. Kanskje du skulle bruke RMI? Hessian? Eller litt REST? Litt WS-* kanskje? Alle er forskjellige, det viktige er å finne ut hvordan du kan utnytte de best. Vær pragmatisk og jeg lover deg at du får en mye hyggeligere hverdag. Dette handler i bunn og grunn om enkle prinsipper og kontroll, men vi har alt for lenge forsøkt å unngå å lære oss disse tingene. Det er på tide å ta til fornuften igjen!
Smidighet bør være middle, ikke målet! Oppnå reelle resultater med noen spesifikke grep
Karol Olivier Dubaele Hårsaker og Per Ivar Gjerløw vil i dette foredraget belyse hvordan man kan hente ut effekten av smidig. Dette er personer med mange års erfaring og har bred kompetanse som ligger til grunn for deres foredrag. Plans are worthless. Planning is essential. - Dwight D. Eisenhower, general and president (1890-1961) Sett det altfor mange ganger; smidighet er målet og ikke middelet. Hvor mange ganger har du ikke hørt: "Da blir det ikke smidig!" Hva er egentlig målet ditt da?
Vi sponser fagkveld med selveste Kent Beck!
Du har helt sikkert hørt om testdrevet utvikling? Eller systemutviklingsmetodikken eXtreme Programming? I så fall bør du sperre opp øynene! Capgemini i Trondheim sponser nemlig en gratis fagkveld med mannen som har skapt dette, selveste Kent Beck - som forresten også var en av de som satt i gang smidig-bevegelsen.
Kent Beck kommer til Trondheim onsdag 24. mars for å holde en intern workshop for oss i Capgemini. På kvelden vil vi sponse en community event som er gratis og åpen for alle. Med dette håper vi å skape enda større entusiasme rundt smidig utvikling i Trondheim.
Agendaen for fagkvelden 24. mars ser slik ut:
18:00-19:00 - Responsive Design
Foredragsholder: Kent Beck
Software design should respond to the changing needs of the system and the growing understanding of the developers. Responsive Design is a discipline of software design that achieves efficiency by working in safe steps. In particular, I will present four strategies for changing the design of a system.
19:00-20:00 – Software Craftsmanship
Foredragsholdere: Tore Vestues (BEKK) og Gøran Hansen (Capgemini)
Software craftsmanship har blitt et populært tema. Det har fått sin egen bevegelse, og har blant annet blitt båret fram av personer som Robert "Uncle Bob" Martin. Hovedfokus i presentasjonen blir på utviklere, men vi kommer også til å ta for oss hvordan dette påvirker prosjektstyring – dermed vil også dette være aktuelt for scrummastere og prosjektledere.
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.
Abonner
RSS feedSist publisert
- Capgemini bidrar på Javazone – du treffer oss der!
- Vi sponser fagkveld med selveste Kent Beck!
- 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