NFRs WTF?

Figyelem egy ideje a fejlesztőket, élvezem a munkát, órákig el tudom nézni, ahogy mások dolgoznak. Viccet félretéve. Próbálok olyan pontokat találni, amivel segítségükre lehetek a fejlesztésben. Minden erőfeszítéssel küzd egy csapat a Technical Debt kiküszöbölésére, mégis jelenség, hogy sok új feladat születik a fejlesztés vélt befejezését követően, amelyek nagy része az ügyfél jelentései alapján inkább a BUG kategóriába sorolódnak, pedig a funkciók a helyükön vannak.

Például: az időzített tárolt eljárások kiválóan működnek a teszt környezetben teszt adatokkal, mégis élesben elszállnak, mert nagyságrendekkel több adatra már más időzítést kell használni vagy akár más eljárást. Említhetném akár a konkurens USER kezelést is.

Az NFRs (Nonfunctional Requirements) megfelelő figyelembevétele és használata azonban megoldást adhat az ilyen jellegű problémák kiküszöbölésére.

Nonfunctional Requirements

Bizonyára sokan találkoztatok már a FURPS mozaikszóval, aminek elméletét – így rendszerezve – a HP dolgozta ki és használta először.

A FURPS (Functionality Usability Reliability Performance Supportability) első F betűje takarja a funkcionalitást, ami rendszerint a storyk-ban meg is jelenik, azonban a Nagyon Fontos URPS nem mindig jelenik meg megfelelő hangsúllyal, előidézve ezzel a fenti jelenséget, miszerint – „azt hisszük, kész, aztán mégsem”.

Ha csak a szavakból indulunk ki, az éles eszű olvasó azonnal felkiált „HÉ! mi az hogyasziszed? MI VAN A DOD-ban? Olvasd el és egyből kiderül, hogy kész van-e!”. Igen, igaza van kedves olvasó, és ha a DOD-ban (definition of DONE – a kész definíciója) csak annyi van, hogy „NRFs – OK?”, akkor itt az ideje kibontani újból ezeket a nem funkcionális követelményeket. Újra, hiszen ezeket már tanultuk az egyetemen… már aki…

Functionality – funkcionális

Funkciók, mire képes, mennyire általános, mennyire biztonságos.

Usability – használhatóság

Emberi tényezők, esztétika, következetesség, dokumentáció.

Reliability – megbízhatóság

Hibák súlyossága és gyakorisága, mennyire hasznosítható, mennyire kiszámítható, mennyire pontos.

Performance – teljesítmény

Gyorsaság, a hatékonyság, az erőforrás-felhasználás, teherbírás, válaszidő.

Supportability – támogathatóság

Tesztelhetőség, bővíthetőség, alkalmazkodóképesség, fenntarthatóság, kompatibilitás, konfigurálhatóság, szervizelhetőség, instabilitás, lokalizálhatósága, hordozhatóság.

Szóval az URPS foglalja magában a nem funkcionális követelményeket. Ha nem elég részletes a DOD-unk, vagy nagyon speciális projektről van szó, akkor javasolt az NFRs külön megjelenítése a SCRUM táblán. Nem kizárt, hogy KRITIKUS nem funkcionális követelmények, mint Story-k megjelenjenek a Backlogban, de ez a PO (Product Owner) felvetése alapján a csapat döntése.

Konkluzió

Ha nem szentelünk megfelelő és folyamatos figyelmet a nem funkcionális követelményeknek, akkor könnyen generálhatunk extra munkát magunknak – amit rendszerint az ügyfél már nem fizet meg – ezért célszerű ezeket a Product Planning és a Sprint Planningek alkalmával alaposan megvizsgálni és a Story-kat ezek ismeretében becsülni.

Nem felejtődhet el ezek vizsgálata, ha betartjuk az egyszerű „meghatároz/tervez – elkészít – tesztel” hármas szabályt. Tervezéskor figyelembe vesszük, teszteléskor megbizonyosodunk róla. Én meg menjek a picsába :)