Større fokus på softwarekvalitet har i sidste ende stor indflydelse på forretningen: bedre softwarekvalitet giver færre fejl, en bedre brugeroplevelse, et bedre omdømme for virksomheden, en større motivation for medarbejderne, og en større tilfredshed – både hos medarbejderne og hos kunderne. Sidst men ikke mindst får man en bedre forudsigelighed omkring softwaresystemet.
Definition
Men hvad er softwarekvalitet? Hvordan skal det defineres? Jeg vil mene at det afhænger meget af hvilken virksomhed der producerer softwaren, og specielt hvilket domæne man arbejder indenfor. Softwarekvalitet afhænger af mange parametre, og det er ikke alle parametre der er lige vigtige hos alle typer IT-virksomheder. Derfor er det meget vigtigt at der udarbejdes nogle retningslinjer om hvad man skal lægge vægt på mht. softwarekvalitet. Det er også vigtigt at hver projektgruppe snakker sammen om hvad de mener softwarekvalitet er for dem.
Værdier
Først er fremmest er det vigtigt at tale sammen om hvilke værdier, der ligger til grund for softwarekvalitet. Eksempler på værdier, der omhandler software, kan være:
- Forståelig kode (hvor nemt er det at forstå koden? Er det en mordgåde man skal løse eller er der et flow man nemt kan følge?)
- Simpelt design (læs denne artikel http://martinfowler.com/articles/designDead.html)
- Robust kode (hvor robust er systemet når der opstår fejl, når det bruges?)
- Fleksibelt design (er det nemt at tilføje nye moduler, eller skal der rettes mange forskellige steder pga. en lille ændring?)
- Testbar kode (er klasserne nemme at teste?)
- Business-værdi (tilføjer den nye feature reel værdi til selve produktet?)
- Konsistens (hvor konsistent er den nye kode i.f.t. den eksisterende kode?)
(billedet er lånt fra dette blog-post)
Hvorfor
Næste spørgsmål lyder: Hvorfor er det værdifuldt at sætte softwarekvalitet så højt?
Det er en god ide at snakke på projektteamet hvorfor man gerne vil have bedre softwarekvalitet. Man kan opdele svaret på “hvorfor” i to kategorier:
- en objektiv og målbar kategori
- en mere subjektiv og knap så målbar kategori
Ang. punkt 1) så er følgende bud på hvorfor det er vigtigt at fokusere på sw-kvalitet:
- Ønske om at minimere teknisk gæld
- Ønske om at minimere risikoen for fejl
- Virksomhedens omdømme forbedres når kvaliteten er i top
- Bedre kode og design
Ang. punkt 2) :
- Større motivation blandt medarbejderne
- Mere indflydelse blandt sw-udviklerne
- Valg af arbejdsplads
Hvordan
Men hvordan får man så en bedre softwarekvalitet i praksis. Her er en række forslag.
- Gå efter kode og design, der er nem at vedligeholde
- Review altid kodeændringer. Og udarbejd en reviewguideline så alle på holdet er enige om hvordan det gøres
- Ryd op i koden. Som Robert “Bob” Martin skriver: Don’t leave “broken windows” (i.e. bad designs, wrong decisions, or poor code) unrepaired.
- Brug spejderdrengsprincippet: “Always leave the campground cleaner than you found it”. Gør det til en vane at forbedre koden, designet eller et byggescript hver gang man tager fat på en ny opgave: fx ændre kode-stilen, opdatere gamle og forkerte kommentarer, bedre navngivning, sletning af død kode osv.
- Brug Continous Integration under udviklingen
- Hver enkelt softwareudvikler bør tage et større ansvar for softwaren
- Fix altid de vigtigste bugs først
- Undgå warnings (eller brug de samme regler for hvilke warnings der er tilladte)
- Refactor koden når det er nødvendigt
- Undgå at genopfinde eksisterende funktionalitet
- Bliv inspireret af eksisterende kode-guidelines (fx disse fra Google: Java og C++, og denne fra Microsoft: C#)
- Foretræk små klasser og korte metoder
- Fælles kode-formatering (fx et pr. sprog)
- Softwareudviklernes forslag skal prioriteres og lyttes til
- Brug open source tools til at monitorere duplikeret kode
- Lav en logging-strategi for systemet, så logging ikke ender med at blive noget rod
- Brug open source tools til fx code coverage (hvor stor en del af koden er dækket af unit-tests?)
En god måde at skabe mere fokus på synligheden af softwarekvalitet undervejs i et projekt er at oprette specielle tasks (eller sætte labels på tasks), der signalerer kvalitetsforbedringer.
Lær af dine fejl
Hvis softwaren bliver leveret hos kunden uden succes, så kan man skylde skylden på mange ting: selve udviklingsprocessen, medarbejdernes engagement, ledelsen, forholdene, manglende kravshåndtering, ingen eller meget lidt fokus på softwarekvalitet etc. Som Kent Beck siger i et interview angående agile processer og den vigtige læringsproces der ligger i at erkende fejl og lære af dem: (http://www.infoq.com/articles/kent-beck-interview-2006):
Somehow we think, “If I was a perfect programmer, the project would have been a roaring success.” If the project isn’t a runaway success, I must be a failure. In this mindset running and hiding becomes a reasonable response.
Det samme er gældende for udbredelsen af bedre softwarekvalitet. Det er sikkert umuligt at få 100% kvalitet i hvert eneste softwareprodukt, men hvis man kan lære af sine fejl, når det angår manglen på et af kvalitetsmetrikkerne, så har man lært noget til næste gang.
Det bør faktisk være et krav, at sætte fokus på softwarekvalitet, når man udvikler software – i stedet for at fokusere på en hurtigere udviklingscyklus. I sidste ende vil det altid kunne betale sig at have fokus på softwarekvalitet fra start til slut. Selvom det kan være svært at måle konkret hvilke fordele man fik ud af det.
“Quality begins on the inside… then works its way out.” ~Bob Moawad
Der er også forskel på om det er software virksomheden producerer…
om det er stand-alone løsninger (web sites) eller enterprise firma løsninger.. eller om det er klodser, eller mælk. Alle steder har brug for KVALITETSAFKLARING (aka Test, så de bliver klogere på hvad der ryger videre).
Koden kan være perfekt mht coverage og de andre metrikker, men hvis den ikke løser problement pga andre omstændigheder, så har vi stadig en dårlig løsning. Så det skal god test også kigge på, og tage stilling til om krav og PBI’er er testbare.
ps: Tests er svært at gøre objektivt målbare: http://www.developsense.com/blog/2013/12/counting-the-wagons/
Tak for kommentaren og linket til blog-postet om tests. Du har ret i at det er vigtigt at sørge for at kravene er testbare. Dvs. hvert krav bliver testet af en eller flere test cases, og at hver test case kan føres tilbage til et krav.
[…] Fokus på softwarekvalitet – In danish…sry! […]