søndag den 19. januar 2014

Om risici ved afholdelse af workshop

Skrevet af Bolette Stubbe Teglbjærg

Kan man lære af andres fejl eller kun af sine egne? Hvis du tænker du kan drage nytte af andres fejltagelser, så læs med her. Jeg vil gerne fortælle om hvordan man ikke afholder en workshop.

Fornylig afholdt jeg en workshop om risk assessment af udvidelsen af en applikation. For mit vedkommende var det første forsøg som facilitator af en workshop og jeg gruede lidt for det. Ikke fordi det var et svært emne eller nogle vanskelige kollegaer, tværtimod faktisk. Men af en erfaren kvinde indenfor branchen havde jeg fået påbud om, at jeg før workshoppen skulle være helt skarp på, hvad jeg gerne ville have ud af den og vigtigst af alt - være i stand til at formulere og kommunikere dette til deltagerne.

Måske på baggrund af dette påbud var jeg længe om rigtig at få fart på forberedelserne til workshoppen. Jeg ville gerne først lave en opdeling af applikationen i funktioner og komponenter, som vi så kunne tale ud fra. Jeg havde også en idé om at deltagerne skulle udføre forskellige opgaver i legoklodser eller modellervoks – indtil jeg blev spurgt hvordan jeg ville vise mit (test-) arbejde i modellervoks. Så blev den idé lagt på hylden. Med det samme.

Til sidst overvejede jeg helt at droppe workshoppen fordi der ”sikkert ikke kommer noget brugbart ud af det alligevel”. Heldigvis er jeg klog og livserfaren nok til at genkende en stor lysende advarselstrekant når jeg ser én, og det fik mig til at indse, at jeg blev nødt til at afholde den fordømte workshop uanset om jeg ville (turde) eller ej.

Jeg vendte tilbage til udgangspunktet og de basale spørgsmål: Ville risk-based testing give mening i dette projekt og hvordan griber jeg det i så fald an?

Projektet jeg er tester på blev fra starten af kendetegnet ved to ting. 1: Det er et risikofyldt projekt og 2: Det er vagt defineret.

Jeg er ene tester på dette projekt som er af relativ kort varighed, så derfor giver det mening at forholde sig til konteksten og spørge: hvis dette er et risikofyldt projekt, hvordan kan jeg bruge denne information til at fokusere og styre testindsatsen hen til dét der er vigtigt?

Jeg afholder en workshop, tænkte jeg. En workshop der har til formål at: i samarbejde at identificere mulige risici i det implementerede system og en vurdering heraf.

Opnåede jeg dette? Nej. I hvert fald kun delvist.

Var der gode lærepenge i afholdelsen af selve workshoppen? Ved jeg nu mere om, hvordan jeg skal gribe én an næste gang? Ja.

Der er risici ved at afholde en workshop. Og her er der 6 punkter der fortæller hvordan du ikke skal gøre:

  • Brug ordet risiko om dine kollegaers arbejde uden at forklare sammenhængen og baggrunden
    • Risiko er ikke et positivt ladet ord, så vær varsom med at sige, at der en risiko ved et stykke arbejde uden samtidig at forklare at det kan håndteres – at du har tænkt dig at gøre netop dette
  • Inviter alle udviklere i projektet
    • Som udgangspunkt vil de fleste softwareudviklere (som jeg kender) hellere kode end at tale processer, kigge på Excel ark eller PowerPoint slides. Hvis der er en ”lead” i projektet som godt kan lide at tale og kommunikere, så inviter ham/hende. Der er ingen grund til at slæbe alle de andre med. Invitér dem evt. som “Optional Attendees”.
  • Afhold workshoppen oveni en bunke andre møder
    • I starten af et projekt er der mange usikkerheder og uvisheder der skal afklares. De fleste søger at finde fodfæste samtidig med de gerne vil i gang med at kode. Hvis udviklerne har travlt og lige har været til en bunke andre møder, så er det måske ikke det rigtige tidspunkt at hive dem (alle) ind til et nyt.
  • Påtag dig alle roller
    • Du kan ikke både være facilitator, tester, skribent og procesleder. Og det skal du ikke forsøge at være. Uddelegér og vælg omhyggeligt dine medhjælpere til at udfylde de vigtige roller.
  • Undlad at gøre det tydeligt hvad målet og formålet med en risk assessment workshop er
    • Hvis deltagerne ikke forstår hvorfor de er der, eller hvad det er du gerne vil, så bliver det svært for dem at bidrage. Hvis workshoppen er til for at hjælpe dig i dit arbejde, så udtryk dette – også mere end én gang. Husk at takke dem for deres deltagelse.
  • Lav om i alle dine slides, Excel-ark, noter og andre papirer kort før workshop start
    • Din forberedelse til workshoppen er din basis, dit udgangspunkt og dét du ønsker at gennemgå med de andre deltagere. Lav det om i sidste øjeblik og du vil have trukket tæppet væk under dig selv, nærmest bogstaveligt talt.

Held og lykke med din egen workshop hvis og når du kommer dertil. Jeg glæder mig til at høre om dine fejltagelser, måske jeg kan lære af dem!


torsdag den 9. januar 2014

Ro, Rytme og Renlighed

Skrevet af Carsten Feilberg

Som udviklingsteam kan vi ofte komme til at referere til det system vi arbejder på som "vores lille baby" og bruge fraser der mest er kendte fra småbørnsfamilier ("skal holde i hånden", "små spæde skridt").

Et gammelkendt princip prædiket mest prominent af Sigrid Riise til nybagte børnefamilier er Ro, Rytme og Renlighed. Og i softwareudvikling og test af samme kan vi også finde anvendelse for disse tre grundpiller, der i årtier har domineret dansk spædbarnsopfostring.

Ro er vigtig, for uden ro er der ingen koncentration og intet overblik. Alting bliver derimod bare hektisk - alting vælder op i en: indkøb man skal huske, møder man skal nå (hvad er klokken egentlig), og jeg skal også lige have ordnet dether, og .. og .. og..

Med ro som udgangspunkt kan der skabes et rum til den aktuelle opgave, i stedet for panik, angst og usikkerhed, drevet af ydre omstændigheder ingen alligevel kan være herre over. Ro er selve det grundelement som skaber os en kreativ oase - ikke dårligt at huske på, i et kreativt fag som vores. Og alt hvad det egentlig kræver er, at vi sætter tid af til at sætte os med opgaven og kun koncentrere os om den. De øvrige ting skal nok melde sig på banen igen, hvis de er vigtige nok.

Rytme, eller regelmæssighed, er ikke altid opfattet som et gode. I en verden hvor der ofte stilles forventning til en om at være tilpasselig, dynamisk og fleksibel - hvorfor så have en rytme? Fordi regelmæssighed er med til at skabe forudsigelighed, og det har vi mennesker også behov for, ind imellem alt det fleksible. Selvfølgelig kan vi alle leve med, at et status-møde flyttes f.eks. en time. Men sker det hver dag, så møder aldrig bliver holdt på det tidspunkt de planlægges til, er den manglende rytme med til at skabe usikkerhed, spildtid og frustration (a la, "jeg kan ikke længere helt planlægge, hvornår jeg kan arbejde på de opgaver jeg har").

Rytme er med til at give forudsigelighed og plads til de ting vi skal.

Renlighed er måske en outsider, når man lige kigger første gang. Enhver der har haft en baby i hænderne er ikke i tvivl om relevansen af renlighed i dén sammenhæng, men i udvikling og test af software?

For mig at se er der en sandhed, som de fleste overser i vittigheden: "hvis et rodet skrivebord tyder på et rodehoved, hvad så med et tomt skrivebord?"
Ja, det er da sjovt, for ingen har jo lyst til at blive kaldt for tomhovedet. Men hold lige billedet af et tomt skrivebord op overfor de to ord vi lige har været igennem: ro og rytme?

Tomhed er ikke forstyrrende, som dynger af papir (som egentlig bare fylder op), brugte kaffekopper, cola-flasker, blyanter og kuglepenne, krummer og hvad jeg ellers i tidens løb har set på både mit eget og andres borde. Det bliver beskidt, støvet og skaber et uroligt billede.

Renlighed er den dyd, der gør at man kan bevare overblikket. Det gør at man kommer af med papirer, hvis relevans forlængst er væk: udprintningen af den C#-metode, der ikke virkede og som nu er skrevet om. Væk med den! Brugte kaffekopper og tømte cola-flasker. Væk! Mødeindkaldelsen fra mødet i sidste uge - som vi kun printede for at kunne huske hvor mødet blev afholdt, da agendaen jo alligevel ikke stod på den. Væk!
Systembeskrivelsen i sit enorme, uhandy ringbind, som blev udskrevet sidste år: Væk! (hvert fald: i det mindste over på hylden)!

Hvorfor skulle det ikke være lidt behageligt, lidt roligt, lidt lækkert at sætte sig foran sin arbejdsstation? Det er i orden at have papirer og ting omkring sig, imens man arbejder - men der skal ryddes op når opgaven er færdig. Ellers bliver ingenting jo aldrig rigtig færdigt.

Den sjoveste historie, som jeg har hørt om dette, handler om en kontor-medarbejder i militæret, der altid havde ryddet sit skrivebord når han gik hjem. Efter nogen tid blev det opdaget, at de ting han ikke nåede at blive færdig med, lagde han i en kuvert til intern post - adresseret til ham selv! Så kunne han næste morgen "starte på en frisk" ved at tømme sin indbakke.
En finurlig og morsom historie, men mest sjov fordi den indeholder et gran af genialitet: vi véd det er næsten snyd, og alligevel vil dette virke (omend intern post i en e-mail-verden, og dog .. men hvordan må du selv finde ud af). Humlen er, at han hver morgen kunne ankomme til et helt rent bord, hvor alting var klar til dagens dont.

Selveste Jamie Oliver har anført dette forhold omkring renlighed. I hans glimrende, omend selvtillidsnedbrydende, serie om "mad på 30 minutter" (hver episode varer lige omkring 23 minutter, just for show-off), starter han de fleste med ordene: "First, clean up your kitchen so you are ready to cook - then ...". Uden at være alt for udleverende kan jeg erkende at dét alene ofte vil tage 30 minutter. Især hvis man har børn i huset - børn af alle slags skaber rod - så vi må tage oprydning alvorligt, hvis vi gerne vil producere noget godt (indsæt selv: software/mad/...). Det hører simpelthen med.

Der er altså noget om det: renlighed er med til at skabe fundamentet for ro - og sørger vi dermed blot for lidt rytme eller regelmæssighed, kan vi lave vidunderlige ting sammen - med alle vores små "børn".
Prøv at tænke over hvor meget ro, rytme og renlighed der er i din hverdag...