Om at slå kanoner med gråspurve

Denne blog handler ikke om test, eller noget som helst andet fagligt. Det handler om dig, og dit virke som person.

Har du egentligt nogensinde spurg dig selv om hvor meget forskel gør du i dit nuværende job? Det er sikkert mange der gør før eller siden, uden at det behøver at være helt eksestentielt.

Hvad med om, on hvor meget forskel er du egentligt i stand til at gøre? Og måske har du overvejet hvilken effekt kan valget af dine handlinger have, når disse vælges med omhu. Det er sådan at det er ikke altid synligt, hvilken betydning vores handlinger har. Som når du sagde noget dumt til en kammerat eller en lærer i skolen og bare gik videre uden at tænke over hvilke tanker og følelser det har medført. Eller når du hilste på en du ikke kender i nabolaget eller bare ude på gaden. Mennesker vælger langt fra altid at vise deres sande følelser, og af samme grund får vi ikke altid feedback for de gode eller mindre gode ting vi selv gør i hverdagen. Ting der med garanti berører andre, i større grad end vi kan forestille os!

Kan du da forestille dig hvilken effekt ville det have at have en kollega som anderkender og roser dig for dine bedrifter? Ikke blot de store ting, som når du har bestået din eksamen med udmærkelse eller er blevet forfremmet.. Udmærkelsen er et ros i sig selv, og måske udvandes de supplerende roser når de blandes og kommer til dig på en gang. Men den ros, der kommer uventet og fremstår enkelt og rammer din egen følelse af bedriftens omfang – det er den der fortjener den største opmærksomhed. Som f.eks når du har siddet og knoklet med en langtrukken og utaknemmelig opgave ingen andre ville have? Eller da du endeligt løst den opgave som viste sig at være ca 200% sværere, mens ingen andre omkring har bemærket det?

Eller hvad med effekten når nogen oprigtigt tilbyder at hjælpe dig med nogle af dine opgaver når du har så travlt at du ikke når at opdage det selv? Dette synes at være lidt svært at tage imod for nogle. Nutidens tendens er blevet at sætte et lighedstegn mellem os sev og vores arbejde, og det er som om det er blevet sværere at takke ja til hjælp — for sæt nu man kommer til at fremstå som en der ikke kan klare sine arbejdsopgaver…. I forlængelse af dette, vil jeg vove at påstå det er også blevet sværere at tilbyde hjælp. For hvis man oplvever at få “nej, ellers tak” gang på gang, så er der også risiko for at man opgiver denne strategi på et tidspunkt. Alligevel, tænk hvilken forskel kunne det gøre hvis nu det var en selv der tog imod når det gjaldt?

Og så ellers effekten af at være positiv og proaktiv i en situation, hvor alt og alle omkring præget af dårlig stemning? Når det virker ligefrem forkert at være “ikke lige som alle de andre” – hvor længe kan det vare ved, og hvem tør at være den første til at bryde muren? Det kræves ikke en førerhat for at være en pioner – og på samme måde kræves der ej heller store overarme for at kunne beskytte vores egne — de folk omkring os der indgår i samme fællesskab. For lad os indse det: om vi vil det eller ej, indgår vi konstant i et eller flere fællesskaber af folk med samme formål. Vores fællesskab i og omrking vores arbejde er unægteligt et af dem. Spørgsmålet er således: hvilken forskel kan du gøre for dit? Når du er en udvikler, er dit job virkeligt at skrive kode? Er du tester, handler din hverdag således kun om at finde fejl?

Måske handler denne blog alligevel lidt om test og faglighed. For siden faglighed trives og udvikles i godt fællesskab, kan vi ej heller forvente gode resultater med fokus på performance hos de enkelte. At gøre hinanden gode sker gennem at gøre hinanden godt. I den professionelle test bygger vi vores gode kompetencer på evner som nysgerrighed, opmærksomhed på detaljer og gode kommunikationsevner men disse kan uden videre bruges på andet end at finde fejl i koden – vi kan spotte uoverensstemmelser i de sammenhænge vi ingår i, og gør vores del for at fællesskabet kommer et bedre sted hen. Hvad med et af de projekter med “umulige” arbejdsbetingelser, hvor overarbejde var normen og alle havde det så og så travlt… Når alle fokuserer på traveltheden, og verden synes at bryde sammen,  kan det være svært at vende blikket udad. Men hvem ville ikke ønske at være i et fællesskab hvor dette var normalen?

To go fast, go alone. To go far, go together

 — African proverb

At gøre forskel på den måde behøver hverken at være betinget af noget filosofisk eller religiøst. Det kan blot være et valg, baseret på indsigt og ikke midst viljen til at have andre med på vejen.

ps: lidt inspiration:

Reklamer

Skal QA være en del af agile teams?

For at sige det lige ud, er der noget som har gået mig på længe: spørgsmålet om den rigtige sammensætning af et agilt team. Et agilt team er jo selv-organiserende og tværfunktionel hvis man følge best-practice, og dermed skal teamet besidde alle de nødvendige kompetencer for at kunne levere et klar-til-release produkt fra iteration til iteration. Det vil sige ingen hængere ift. test, ingen afsluttende “test runs” så test må ikke være en flaskehals. Betyder det så at test bør være en stærk kompetence hos et agilt team? Ja! Er det så ikke bare med at ansætte flere testere?

Sagen er at titler og roller som “Tester” udvandes i den agile ideologi. Mens der er mange agile teams benytter sig af Scrum, skriver Ken Schwaber og Jeff Sutherland i deres “The Scrum Guide” fra 2013 om et typisk Scrum team:

  • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.
  • Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Så der er ingen titler, ingen undergrupper og ansvaret ligger altid hos teamet. Det er netop op til teamet at søge de nødvendige kompetencer – enten ved at tage dem ind på teamet eller søge dem ude. Traditionelt har testen ligget til sidst i udviklingsprocessen, selv om gode intentioner har forsøgt at skube den tidligere, som i V-modellen.

På et agilt team tester vi ideelt hele tiden, så snart der er noget klar til det. Realiteten kan være en anden – det afhænger af hvor god er teamet til at planlægge og styre igennem mængen af opgaver, så der er noget at lave til alle.

Efter nærmere overvejelse hos den lokale HR manager tilknyttet vores fiktive team, bør testerens profil matche typen af de test opgaver der kan forekomme:

  • Tidlig test kan være at review’e stories og accept kriterier for at sikre dem efter INVEST og på den måde få kvalitetssikring tidligere ind i processen
  • Tidlig og løbende test er at sikre alle acceptkriterier er testet, intet er glemt og eventuelle ændringer (som helt sikkert vil være der!) er reflekteret i fælles forståelse og evt dokumentation i form af tests eller tekstuel beskrivelse
  • Tidlig test kan indebære review af arkitektur med henblik på testbarhed.
  • Tidlig test kan indebøre review af produktionskode og input til automatiseret test (som regel kode igen)
  • Tidlig test kan indebære at teste REST/ API interfaces med tools, både funktionelt og måske med heblik på performance og sikkerhed.

Disse er blot for at nævne nogle, ud fra egne erfaringer – men de illustrerer ret godt et billede af en mere teknisk profil der er i stand til at arbejde sammen med teamet meget tidligt i processen. Samtidig har profilen en rigtig god forretningsforståelse, overblik og kommunikationsevner. Findes der sådan en rolle vi kan “hyre ind” på teamet?

Der er højst sandsynligvis få som er gode til det hele på en gang. Og det er netop pointen med agile / scrum teams at der skal ikke være sådan nogle roller! Kompetencer bør være spredt, og ideelt kan udviklere også teste, mens de test mindede førhenværende testere skal kunne finde sin anvendelse i at understøtte testen på alle mulige måder — også ved at skrive (test) kode. Hermed er agil QA født som en kompetence, snarere end en rolle!

Poul sagte:

  • Agil QA: et mindset du kan tilegne dig for at blive rigtig god til at kvalitetssikre(ok det er nok ikke kun mig der har sagt det, men jeg har i hvert faldt skrevet det her)

Tilbage ved spørgsmålet om hvorvidt bør QA være en del af et agilt team: forudsat teamet har et behov, er det en rigtig god ide! Jeg ved at svar der indeholder et “men” har en begrænsende virkning, så måske kunne man formulere det som “det afhænger af kontekst, såsom teamets sammensætning og typen af opgaver”.

Hvis teamets mindset ligger langt fra “vi skal også tænke på testbarhed og teste selv”, eller når disse mangler decideret som kompetencer — så kan man ikke komme udenom det. En eller flere personer med stærke kompetencer, eller om ikke andet viljen til at lære QA kan så frø og starte en kultur hvor test er en naturlig test af udvikling (så ja til en dedikeret QA i en periode). En del af opgaven vil også være at lære teamet om QA, hvilket er ret svært uden at være en del af teamet.

Et mere modent team med kompetencer i kvalitetssikring kan måske undvære en dedikeret QA i en periode. Der vil dog være fare for at fokus på god kvalitetssikring vil blive udvandet, og her kunne man tænke et setup hvor QA rollen er “assisterende” i form af en Test Coach der både kan stille de rigtige spørgsmål og rette teamets opmærksomhed efter de ting som kræver dette. Men hvem bestemmer så om hvorvidt teamet er modent nok til at undvære en dedikeret QA..? Jeg ville ønske jeg kunne være fagligt korrekt og skrive “teamet”, men i realiteten har organisationen ofte den sidste ord. Økonomi, projektmål og politik vil jeg ikke ind på i dette indlæg, så tilbage står en klar anbefaling om at teamet i hvert fald giver udtryk for hvad er i deres overbevisning et behov for at være gode og effektive til deres arbejde, og ikke mindst selv søge veje derhen (hvilket jeg også skrev om i et tidligere indlæg).

ps. på samme måde kunne man tage en dialog om roller / kompetencer som user experience (UX), Business Analyst (BA) osv. Hvis teamet laver et produkt der er afhængig af god UX, skal denne kompetence ikke være en mangelvare eller en flaskehals. Selv den bedste dedikeret UX’er tage på ferie, blive sygmeldt eller generelt  være en eftertragtet person alle vil tale med 😀 – et agilt team bør ikke være afhængig af enkelte personer hverken på eller udenfor teamet!