Projekttriangeln, buggar och defekter

Nyligen snavade jag över en gammal artikel av Eric Ries, som vad jag förstår är mannen som myntade begreppet Continuous Delivery. Han argumenterar där för att dela upp fel i två fundamentala begrepp: defect och bug. Jag attraheras av idén med den tydliga uppdelningen men är tveksam till ordvalen.

Defect representerar här ett beteende i systemet som får en funktion i systemet att avvika från den funktion som den som konstruerat funktionen avsåg. Här avses främst alltså något som är trasigt.

Bug representerar då en funktionsmässig avvikelse från kravspecifikationen. Här inryms bl.a. fallet att kravspecifikationen är trasig och systemet gör rätt.

När man testar ett system går dessa två fall ofta inte att särskilja. Det är först sedan man utrett grundorsaken denna klassificering kan ske.

Jag tror inte att defect och bug är rätt ord. Terminologin verkar problematisk och det finns olika tolkningar av defect och bug med avvikande definitioner.

Hur som helst, om vi för ögonblicket glömmer ordvalet, genom att klassificera felen på detta vis använder han detta som tillhygge för att såga parafrasen ”Tid, pengar och kvalitet, välj två”. Jag har också lärt mig den en gång i tiden men känner numera också viss tveksamhet inför dess giltighet i mjukvaruprojekt. Men, det beror nog också på vad man lägger i ordet kvalitet.

projekttriangel

Jag noterar att man i Wikipedia bytt ut Kvalitet mot Scope och låter kvalitet utgöra arean. Det känns mer relevant.

En defect måste alltid fixas. En defect är som regel inte en diskussionsfråga med produktledningen. Alternativet till att rätta den är att ta bort koden (och dess funktion) som innehåller denna defect.

Fel av typen bug releasar man alltid med, frågan är bara i vilken mängd och i vilket urval. Det är en förhandlingsfråga och skall prioriteras tillsammans med nya funktioner.

Jag har hittils praktiserat denna uppdelning genom att påverka prioriteringen av fel och inte flagga en funktion som klar om inte alla fel på den som faller inom definitionen för defect är borta.

Artikeln i övrigt är för mig en kavalkad av igenkännanden, där jag sett det mesta i stora mjukvaruprojekt, kanske med flera teams, där man omväxlande rundar hörn, står med högvis med fel och delvis tveksam kod och stora förseningar och omväxlande refakturerar och tar omtag för att inte stå och kvar och stampa eftersom ryggsäcken blivit för tung.

Skillnaden mot situationen i artikeln där teamet inte hade CI alls är att jag i de projekt jag deltagit i under modern tid haft enhetstest med acceptabel täckning, Continuous Integration och automatisk systemtest, dock den senare av varierande kvalitet och omfattning. Ändå känner jag igen problemen och av detta drar jag slutsatsen att man måste ha klivit en bra bit upp på den här stegen innan det känns som om saker börjar flyta på bra.

Jag kan bekräfta att de kvalitetsproblem och leveransproblem som Eric beskriver och som lätt kan uppstå i en stort system som utvecklats under lång tid går att arbeta bort om man målmedvetet arbetar med enhetstest, kodkvalitet, TDD, förbättrar testtäckning, refakturerar, jobbar med väl vald och avgränsad redesign, inför och kör CI med automatisk integrationstest och har substantiell testtäckning. Är systemet stort kan denna process ta flera år.

Jag kan också bekräfta att gör man rätt från början och inte drar på sig en stor ryggsäck med dålig kod utan automatiska tester blir det totalt sett mycket mindre arbete. Man slipper de flesta av de problem som beskrivs. Men det är å andra sidan en ständigt jakt och en vardaglig kamp där vi får använda hela vår kunskapsarsenal inom mjukvaruutveckling för att hålla oss på spåret, och det är lätt att hamna vid sidan om man släpper vaksamheten eller börjar slarva in kod i repot.

I det lilla är det inte mer spännande än det snusförnuftiga “gör rätt” och “gör klart”. Ta alltså bort all kod, funktioner och tester som inte är rätt eller inte är klara. Men bäst är så klart att aldrig lägga in dem.

Det här är förstås lätt att säga, och kanske på gränsen till irriterande, men det finns ett nyckelord som jag upplever gör detta möjligt, eller i alla fall lite mindre omöjligt, och det är att reducera scope för funktionen/uppgiften till dess att man i rätt tid och med rätt kvalitet kan leverera en funktion med tillhörande automatiska regressionstester, såväl enhetstest som acceptanstest.

Eric beskriver vidare hur man kan motivera automatisk test på ett sätt som jag gillar:

If the business leaders were told ”this feature is done, but only for an indeterminate amount of time, after which it may stop working suddenly” they would not be so eager to move on to the next new feature.

Om man gör rätt och gör klart i små steg och inkluderar automatisk test så har man kommit långt och praktiserar då också grunderna i det som kan ta oss mot Continuous Delivery.

sommarläsning

Kvar att utreda nu är varför summan av alla naturliga tal blir minus en tolftedel.

IT Consultant at CAG Edge. Cloud and Continuous Delivery specialist, software developer and architect, Node.js, Java.

Publicerad i Agile, Continuous Delivery, Test

Kategorier

LinkedIn Auto Publish Powered By : XYZScripts.com