Agile testing - hvordan skal denne disciplin organiseres??

(note: indlægget her ser bort fra TDD og unit-testing, som selvfølgelig er en del af udviklernes arbejde)
Vi har pt. ikke dedikerede testere tilknyttet vores projekter. Det bliver løbende et større og større problem, da det både kræver, at udviklere og product owners (vores forretningsudviklere) bruger en stor portion af deres tid på at teste.

Jeg anser det for et problem fordi

1. Udviklere er naturligt "blinde" overfor fail-scenarier. Man selv har skrevet den kode, logik og funktionalitet, som skal testes, og i mange tilfælde vil man derfor let komme til overse en række boundary cases, fordi man tænker i "positiv" scenarier i forhold til den kode, man lige har skrevet.

"... the term ‘FUT’ (frequent unit testing) for the activity of creating unit tests along with the software code, regardless of whether the tests or the code are created first. And then he goes on to say that the risk with FUT is that ‘blindness’ may prevent the developer from writing tests for
the edge cases he did not consider when coding the application.", http://www.developertesting.com/archives/month200501/20050131-BlindSpotsFrequentTestingSoftwareAgitation.html

2. Kunden/Product owner er heller ikke nødvendigvis den bedste til at optænke alle nødvendige tests. For det første er ens fokus på udvikling af en given forretning, og man har ikke nødvendigvis det kompetencesæt, som er påkrævet. Derudover har man heller ikke tid, da man jo er travlt beskæftiget med at udvikle og drifte en forretning.

I min forestilling er der behov for mindst én på et projekt, som har sit fulde fokus på softwarens kvalitet. Dette sikrer, at kvalitetsprocedurer overholdes og gør det muligt at opfange fejl/mangler tidligere i forløbet og dermed spare refaktoring-tid i en sprint.

"Being in a more detached role, sometimes the tester can see a neckbreaking hairpin curve in the road before everyone else.", http://www.testing.com/agile/crispin-xp-article.pdf

Derudover skal der være i hvert fald en i QA linieorganisationen, som har det overordnede ansvar for kompetenceudvikling og retningslinier for testere på de forskellige projekter. Det skal også være denne afdelings ansvar at sige go eller no-go til projekter ud fra kvalitetskravene.

På testing.com fandt jeg et ret interessant eksempel på, hvordan agile testing skal organiseres og hvorfor:

"Rather than communicating at people, we need to join and encourage the ongoing
project conversation. Testers and developers should sit in the same bullpen,
share offices, or occupy alternate cubicles. Many testers should be assigned to
help particular developers, rather than to test pieces of the product. The test
plan should evolve through a series of what James Bach calls "drop-in meetings"
- short, low-preparation, informal discussions of particular topics. These will
result in what James Tierney calls "test doclets" - short memos addressing a
specific issue. Test status should be reported via big, public, simple-to-read
charts that answer specific development questions like "what parts of the
product can we stop worrying about?", http://www.testing.com/agile/agile-testing-essay.html

Jeg kan godt lide det fokus på kommunikation, der vægtes i ovenstående citat. At testere skal assignes til at hjælpe en eller flere udviklere, istedet for at teste et eller flere områder af en applikation, virker soleklart på mig. Det drejer sig jo om at undgå distancering og ansvarsfraskrivelse i sidste ende, hvis man altså ønsker at være virkelig effektiv.

Jeg kunne godt tænke mig at høre jeres ideer til emnet, og hvis muligt høre fra nogen af jer, som har implementeret lign. i jeres organisationer.

PS: et udmærket link til udforskning af holdninger og tilgange til emnet kan findes her: http://www.testing.com/agile/

Hvem arbejder en projektleder for?

Jeg er af den overbevisning, at dem der laver arbejdet er nødt til at have nogen, der arbejder for dem, til at fjerne støj og forhindringer så arbejdet kan udføres.

En projektleder arbejder for projektgruppen, og skal sikre, at den er glad og kan "levere, levere og levere"

Projektchefen arbejder for projektlederne, for at sikre at projektlederne får mulighed for at udføre deres arbejde.

Selvfølgelig er der andre aspekter af arbejdet som projektleder, men det er alt sammen noget der i sidste ende skal give ro til projektgruppen, så holdet kan levere resultater og bundlinie.

Jeg kom til at tænke på dette, da jeg faldt over managinghumans.com - er der nogen her der har læst bogen?

Teams og Gandhi

Tyvstjålet fra et indlæg på lifebeyondcode kommer her et Gandhi-citat:

"A small group of determined spirits with an unquenchable thirst for their mission, can alter the course of history".
- Mahatma Gandhi

Rajesh Setty (bloggeren på lifebeyondcode) bruger citatet til at filosofere over sin personlige indstilling til livet, men jeg tænkte selvfølgelig straks på projekter og teams.

"..determined spirits with an unquenchable thirst for their mission" - dette er for mig at se kardinalpunktet for ethvert projekt. Hvis man sikrer at teamet arbejder mod samme og meget nøje defineret målsætning, og at alle individder i teamet kan se deres funktion i opnåelsen af målsætningen, så kan man sku "...alter the course of history"! Så lad det blive en god notabene til alle projektledere...

Giv magten til dit team #1 - Medbestemmelse

På det seneste har ideen om motivation af projektteamet fyldt mit sind meget. Derfor har jeg tænkt at starte en føjleton på området, som sikkert kunne skabe lidt sund debat :)

Grundlæggende bygger mange agile processdiscipliner på en antagelse om at motivation og empowerment af projektteamet er væsentligt for at kunne skabe gode resultater, og indenfor softwarebranchen dermed god software. Eksempelvis har Scrum sit udgangspunkt i at projektteams/udviklingsteams skal være selvorganiserende for at kunne levere fremragende software tilpasset kundens, produktejerens, ønsker og behov.

Jeg kunne godt tænke mig at dykke lidt ned i, hvad der gør et super team, og her tænker jeg specielt på, hvad man som leder kan gøre gøre for at sætte scenen i den forbindelse.

Første ting jeg har tænkt mig at skrive lidt om er noget som ligger mig meget nært i mit ledelsesarbejde: medbestemmelse, så her kommer det...

#1 Medbestemmelse
I modsætning til traditionel management tankegang, hvor projektlederen udstikker opgaver og får projektteamets medlemmer til at løse dem, så tror jeg på, at teamet selv skal lede og fordele det stykke arbejde, som de udfører. Projektlederen skal blot fascilitere at dette bliver gjort og bistå med gode indspark til processen, hvor nødvendigt. Dette er væsentligt af flere grund, men vigtigst er dog, at man som projektleder skal befri sig fra kontrolcenter-metaforen, hvor man kan sidde i sit eget skønne elfenbenstårn og styre sine projekter via flotte charts og reports. Teamet skal deltage i centrale beslutninger for projektet. På den måde får man også flere perspektiver på en given problematik, end man ellers ville have gjort. Som projektleder bør du

1. Involvere dit team i beslutningsprocesser, som omhandler teamet eller det produkt, som der arbejdes på
2. Sikre at teamet er klar over sit ansvar
3. Gøre det klart for teamet, at de har de kompetencer, der skal til for at kunne træffe de rigtige beslutninger
4. Sikre at der altid følges op på de beslutninger, der træffes (dvs. får dem omformet til planer, kommunikeret til stakeholders etc.)

Hvad får du ud af at gøre det? I mine øjne er der nærmest kun gevinster at hente (hvis det rigtige setup etableres):

1. Du får adgang til en meget bredere, og multi-perspektiveret, vidensbase (som i tekniske henseender er langt mere kompetent end du nogensinde kan være)
2. Ved at spørge teamet nedarves der konsensus for forslaget, som skal vendes. Teamet kommer op med løsningsforslag, som bliver til planer, og disse planer vil i sidste ende være produktet af løsninger tænkt af teamet selv og ikke af dig
3. Når mennesker adspørges om deres mening, så arbejder de hårdt for at komme op med gode ideer. Dette er et kæmpe plus, når man står midt i en kritisk situation i sit projekt og skal træffe vigtige beslutninger, om hvilken retningen arkitekturen eksempelvis skal tage

Medbestemmelse betyder dog ikke, at du kan læne dig tilbage og lade andre beslutte alt for dig. Du skal skabe det forum, hvori medbestemmelsen opstår, men som ordet medbestemmelse også ligesom indikerer, så er du også selv en deltager i processen. Måske beslutter du ikke noget om teknikken, men måske har du gode retningslinier for tænkningen eller scopet af diskussionen.

Sidst vil jeg lige nævne, at medbestemmelse også stiller store krav til projektlederens rolle som leder. Projektlederen skal være den toneangivende og altid gå foran som det gode eksempel. Hvis man som projektleder lader teamet træffe beslutninger på halvt grundlag, hvad lærer man så sit team? - At det er ok at træffe beslutninger på ufuldstændig information.. osv.

Kliche, floskel eller ej - teambuilding uden for kontoret er godt!

Vi har i dag spenderet en hel dag i Ebeltoft Zoo, eller rettere Ree Park, på både at diskutere værdier i IT-organisationen og løse praktiske fysiske opgaver i teams. Det er efterhånden en fortærsket kliche, at den slags virker, men alligevel vil jeg nu gerne have lov til at råbe det lidt igen: at lave noget sammen udenfor kontorets rammer, det booster sku team-spirit, korpsånd og venskab! Jeg tror mange har tendens til at tilsidesætte den slags tiltag, fordi de virker floskelagtige og "set før"... men måske er der en grund til at de virker som "set før"? Jeg er sikker på, at IT afdelingen vender tilbage på mandag med forfrisket ånd og styrke. Mere af den slags, tak.

Ønsker man at basere sin organisation på team-arbejde, så bør aktiviteter som nævnt i dette indlæg ikke forbigås. Der må også meget gerne følges op på den slags aktiviteter, så man som team og organisation kan forbedre sig og lære af sine erfaringer.