Sagan om projektledarkråkan som skulle ut och åka

Detta är sagan om projektledarkråkan som skulle ut på en resa med sitt projekt men inte hade någon som styrde över kvalitetsaktiviteterna. 

Projektledaren kan vi kalla Håkan för enkelhetens skull. Håkan hade varit med i gamet ett tag och kände att han hade koll på hur projekt skulle bedrivas. Dessutom var han omgiven av väldigt kompetenta utvecklare, enligt sin egen mening. Detta innebar att Håkan inte hade mycket till övers för olika aktiviteter för att säkra kvaliteten. Det brukade ändå lösa sig på slutet då man körde igenom några testfall för att se att saker och ting snurrade. Håkan hade nyligen läst om Scrum och fann det tilltalande att arbeta på detta sätt eftersom man då snabbt kunde komma igång och producera kod istället för att ha långa diskussioner med kunden. Det kunde man lösa på vägen helt enkelt förstod han, efter att ha läst om lyckade projekt på nätet.

Projektet drog igång och man hade arbetat med kunden Kurt tidigare. Därför ansåg man att man hade en bra uppfattning om vad Kurt ville ha. Dessutom kunde Kurt vara ganska obeslutsam så man var inte så intresserad av att sitta i en massa möten med honom och diskutera krav. Man skulle köra Scrum och då skulle det lösa sig på vägen. Några av utvecklarna hade också läst en del om agil utveckling och fastnade för att sätta upp en automatiserad byggmiljö och man producerade även ett antal automatiserade testfall som skulle köras när man gjorde ett nytt bygge. Tyvärr hade man lite svårt att få dessa testfall stabila och de uppdaterades inte efterhand som koden förändrades. Efter ett tag blev det att man helt enkelt inte exekverade dem.

Samma sak hände med morgonmötena. Det kom egentligen inte upp något speciellt och alla hade koll på vad de skulle göra så man tyckte helt enkelt att det var bättre att lägga denna tid på att producera kod. Tanken var även att Kurt skulle vara med på demonstrationerna men eftersom han hade fått mer ansvar var han tvungen att resa ganska ofta vilket förhindrade honom att delta på dessa. Håkan löste detta genom att även ta på sig rollen som produktägare eftersom han ju visste vad Kurt egentligen ville ha.

Det rullade på och dagen för leverans närmade sig och man började köra lite manuella tester i sin utvecklingsmiljö. Håkan tyckte det såg bra ut även om det fanns några små konstigheter om man gjorde saker som man inte borde göra med systemet. Med andra ord skulle det lösa sig. Systemet levererades till Kurt som tillsammans med några kollegor började acceptanstesta systemet i sin produktionsmiljö. Det Kurt såg gjorde honom inte glad. Vissa funktioner fanns inte med, det fanns saker som han inte förstod varför de fanns med, prestanda och tillförlitlighet var under all kritik samt att en av de viktigaste punkterna, användbarheten, var helt förbisedd. Projektet hade kört rakt ner i kvalitetsdiket!

Håkan skyllde på Kurt att han inte hade varit tydlig eller närvarande i projektet medan Kurt skyllde på Håkan för att han inte hade lyssnat och kört projektet på sitt eget sätt. Det ingen av dem såg var att det inte fanns någon som styrde test- och kvalitetsarbetet när projektledarkråkan skulle ute och åka...

Sensmoralen från denna saga är att det inte bara går att läsa något på nätet och sedan tro att man kan implementera det rakt av och få det att snurra. Det vi ser idag är att både mer traditionella projekt och agila projekt kör i diket på grund av att många projektledare och beslutsfattare inte har förståelse för varför test och andra kvalitetssäkringsaktiviteter behövs och hur dessa skall genomföras på bästa sätt, beroende på vilken utvecklingsmodell man har valt.  Det krävs utbildning, kunskap och erfarenhet om man vill undvika detta!

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

Dr. Magnus C. Ohlsson,
Quality Assurance Specialist