Resten af gaven må vente lidt endnu. Men det kan dog afsløres at den indeholder en flyvetur på over 6500km :-D

Transparens når det går dårligt kan umiddelbart virke som en negativ konsekvens ved scrum. Men at alle alle tydeligt kan se at det går skidt er GULD værd – fordi synligheden helt naturligt provokere en reaktion. Helt konkret muliggjorde synligheden at vi som scrum team blev tvunget til at gennemgå en lang række uhensigtsmæssigheder i vores måde at arbejde på (både organisatorisk og personligt). Og denne italesættelse af uhensigtsmæssighederne gør det muligt at bearbejde, og ideelt set fjerne dem helt. Under andre udviklingsformer ville vi som team have ”lukket af” over for omverdenen og derved have skjult – men ikke løst problemerne.

Helt konkret fik vi som følge at vores synligt dårlige performance diskuteret forskellige scenarier på hvordan vi skal håndtere tasks der ”vokser” jo mere der arbejdes på dem, og derfor sætter teamets hastighed i stå. Det kan være tasks der bygger videre på kode der i løbet af sprintet viser sig at være af for dårlig kvalitet, og derfor skal refaktoreres ud over det forventede. Eller tasks hvor de tekniske usikkerheder viser sig at være anderledes end antaget i sprintplanlægningen.

Vi fik vendt nogle af de organisatoriske fordele ved ”fail fast”, og at det kan være bedre at afbryde et sprint tidligt, end at fortsætte imod et urealistisk mål – hvis det viser sig at forudsætningerne for et sprint ikke er tilstede. Og vi fik snakket en række konkrete indgreb igennem som vi i fremtiden vil benytte hvis fremgangen en task går i stå.

De indgreb vi snakkede igennem var blandt andre at splitte et kode-par op og blande nye personer ind på en opgave der går fast, og at tasks der viser sig større end først antaget bør splittes op af hele teamet, og ikke kun de personer der aktuelt sidder med den pågældende task – også for at få delt designbeslutninger ud som en team-beslutning.

Scrum er godt – specielt når det går skidt :-)

Et af de sidste integrations projekter der mangler for at CMS’et er istand til at overtage alle eksisterende sites, er integration med person data (fra administrationens PDS – Person Data System), så det er muligt at generere automatiske medarbejderlister på div sites. Og det er netop dette vi pt. arbejder på.

Dette arbejde har affødt en del teknologiske udfordringer fordi datakilden (PDS) ikke egner sig særlig godt til vores brug da både hastighed og dataformater er ikke velegnede til at generere medarbejderlister ud fra. Vi har derfor været nødsaget til at “pakke” datakilden ind for at kunne holde vores kvalitetskrav omkring leveringstider (95% af alle sider inden for 1 sekund).

Dette har været en oplagt mulighed for at få taget fat på ideen om AAU-data som RESTfull webservices – og der er blevet taget hul på den helt store JAX-RS impelmentation af en medarbejderliste REST resource, hvorfra CMS’et og en række andre applikationer kan trække medarbejderlister.

Forhåbentligt kommer dette til at være den første af mange data som bliver udstillet som RESTfull webservices hos AAU, og jeg håber at vi med tiden kan udstille disse, så alle interesserede kan lege med dem. Forhåbentligt er der nogen der kan bygge applikationer eller mashups på baggrund af disse data – og det kan måske være med til at ændre silotankegangen der desværre er meget udbredt på AAU.

Som altid ved sådanne “brede” arrangementer, var det ikke alle oplæg der var lige givtige –  mest fordi der var meget stor spredning i de forskellige deltageres arbejdsområder og erfaringer inden for  UI arbejde, men alle oplægsholderne klarede sig glimrende under disse noget utaknemmelige forhold.

Der skal dog specielt sendes ros til Ingrid Haug der præsterede et rigtig godt oplæg om løbende inddragelse af brugervenligheds-metoder og overvejelser i udviklingsprocessen. Ingrid kom med en række konkrete eksempler på synliggøreles af brugervenligheds-mål i hele organisationen, og dermed med til at holde fokus på kundernes behov og ønsker. Ingrid kom blandt andet ind på:

• Eksempler på brug af konkrete brugbarheds-mål til evaluering (eks: 80% af vores brugere skal kunne gennemføre opgave X på Y sekunder) og at synliggøre disse med smilies – fuldstændigt som hos den lokale pizzamand.
• Iterativ sammenspil imellem usability-evalueringer og design-processer (så meget som man nu kan i en vandfaldsmodel af næsten Niagara-proportioner)
• Personas, baseret på en ekstrem imponerende case fra Microsoft

I Microsoft casen (fra udviklingen af Microsofts ERP produkter) havde MS lavet en hel virtuel virksomhed. Denne fiktive virksomhed bestod af en lang række personas, og disse blev synliggjort denne gennem plakater, websider mm. i hele udviklings-organisationen, så alle der var involveret i projektet viste “hvem” kunderne var – virkelig imponerende.

Dette muliggjorde at alle kunne snakke om kunderne i et naturligt sprog, og at undgå den klassiske “brugerne”-formulering der typisk resulterer i en en-dimensional forståelse af brugergruppen. Og for lige at gøre det lidt mere imponerende var ALLE personas baseret på interview, og alle informationer udstyret med kilde henvisninger. - PDF med oversigten over MS personas (0.9Mb)

Hatten af for MS for deres persons arbejde, og for Ingrid for at kunne formidle en lang række metoder og teknikker på et højt niveau til en broget flok af nørder.

Næste møde i den oprettede interessegruppe blev sat til d. 16 juni i Århus, og baseret på dette for-møde kan jeg kun anbefale folk der har interesser inden for bruger-venlighed/inddragelse at holde øje med Infinits hjemmeside.

I skemaet herunder er alle planter der er spiret på nuværende tidspunkt (når der kan ses kimblade). Og jeg har tænkt mig at opdatere skemaet løbende her på min blog.

Alt der mangler nu er lys – og alt sneen forsvinder… der kommer billeder på et tidspunkt når der er lidt mere at vise end små ranglede skud, med kim-blade.

Jeg har fået sået hele 11 forskellige sorter, og hvis alt lykkedes, indeholder årets plan både potter (som tidligere), plante kasse, hydroponisk dyrkning og måske også bonzai – men det kommer lidt an på hvor successful spiringen forløber.

"Chili 2010" album fra flickr

Sorterne der blev udvalgt til i år lægger sig stærkt på Habañero varianter, og lidt klassikere.

1. Chocholate Habañero
2. Habañero White
3. Fatali
4. Habañero Orange
5. Habañero Hot Lemon
6. Lemon Drop
7. Long Purple Cayenne
8. Tabasco
9. Golden Cayenne
10. Bulgarian Carrot
11. Early Javapeño

Alle sorter er sået i kokos tabs (Jiffy) istedet for alm jord for at få et inaktivt medie (hvis hydro setuppet bliver til virkelighed)

Jeg har startet et album på flickr som løbende vil blive opdateret med årets chili-billeder. Jeg skal også nok sørge for at lave nye posts når der sker noget spændende, men da det typisk tager nogle dage før frøene spirrer, går der nok minimum en uges tid.

Og der er naturligvis søgning langs ruten og meget andet glasur på kagen. og som om det i sig selv ikke skulle være grund nok til at forvise sin Garmin til de evige jagtmarker så koster det gratis! jeps GRATIS! Eneste catch er at man skal vente på at få fat i en telefon med Android 2.0 for at lege med, og naturligvis straffe sin 3G forbindelse på det groveste, men det virker en del smartere end at betale Gramin 1K kr om året i kort opdateringer.

Kristian vil ha!

Udbyttet af JAOO er som altid utroligt afhængig af at man tager til de “rigtige” sessions. Og da løst kobling imellem services er et helt centralt element i min måde at tænke systemudvikling på, var REST tracket om tirsdagen en af de ting der trak.

Det var utroligt lærerigt at se hvordan ws-* webservices (eller ws-death-star som det blev omtalt) helt er faldt i baggrunden for REST baserede webservices. Og at selv om REST tilsyneladende er en simpelere tilgang – kræver en endnu højere analytisk og metodisk tilgang til data distribution end SOAP baseret arkitektur.

Html5 tutorialen var meget spændende, da der blev præsenteret en række muligheder for at benytte html5′s kommunikations muligheder (bla websockets) INDEN der er support for disse teknologier i browseren. I praksis foregik det ved transparent at falde tilbage på en lang række propriortære teknologier, men UDEN at man som udvikler på noget tidspunkt skulle tænke over det – ud over at inkludere et script i sine applikationer – elegant!.

GWT tutorialen var også meget lærrerig, men ikke lige så cutting edge som html5 sessionen. til gengæld var GWT tutorialen fuld af tips og triks som jeg ummidelbart kan begynde at bruge.

Alt i alt får Trifork et 10-tal efter den nye skala for årets konference – (Karakteren 10 gives for den fortrinlige præstation, der demonstrerer omfattende opfyldelse af fagets mål, med nogle mindre væsentlige mangler).

fra http://www.number10.gov.uk/Page20571

… He truly was one of those individuals we can point to whose unique contribution helped to turn the tide of war. The debt of gratitude he is owed makes it all the more horrifying, therefore, that he was treated so inhumanely …

Bedre sent end aldrig.

Dette skal dog ikke forstås således at jeg er af den opfattelse af at det ikke er farligere at køre på mc end at køre i bil – det tror jeg alle der har bare en basal forståelse for fysikken der er involveret i et færdselsuheld og mennesklig fysiologi sagtens kan gennemskue – der er trods alt ikke noget der hedder “lille uheld med små buler” når man køre på motorcykel!

Men nok snak, man er vel ingeniør, og så er det bare om at grave de egentlige tal frem.

En hurtig søgning på google viser dog at der er andre der allerede har lavet arbejdet for mig (i en underøgelse af knallert45, men en af de transportmidler der samlignes med er netop mc)

Fra rapporten 45-knallerter – kørekort, risiko, hastighed, uheld fra sikkertrafik.dk bliver der på baggrund af data fra dansk statistik konkluderet at:

Risikoen ved kørsel på 45–knallert er beregnet til 20 (antal dræbte og alvorligt tilskadekomne pr. 10 millioner km). Risikoen ved kørsel på motorcykel er også beregnet til godt 20, hvorimod risikoen ved kørsel på almindelig knallert er beregnet til ca. 30. Risikoen ved kørsel på 45–knallert og motorcykel er således den samme.

Det er altså 50% farligere at køre på knallert end på motorcykel.

En lille sidebemærkning omkring risikoen på 20 skader/dræbte pr 10.000.000 km – Det er en skade/dødsfald pr 500.000km eller ca en anvorlig tilskadekommen eller dræbt hvergang der er kørt 12,4 gange rundt om jorden!.

Egenrisiko 45-Knallert 30 km Knallert Motorcykel