Ikke-funksjonelle krav i Scrum
Hva er ikke-funksjonelle krav?
Man kan si at dette beskriver hva et produkt er (eller skal bli), mens funksjonelle krav beskriver hva det gjør (eller skal gjøre). Funksjonelle egenskaper håndterer vi enkelt gjennom å beskrive synlige funksjoner i brukergrensesnittet – i Scrum som Product Backlog elementer. User Story formatet er godt egnet til dette. Ikke-funksjonelle egenskaper/krav er slikt som kompatibilitet, sikkerhet, ytelse, responstider, forsinkelse, vedlikeholdsvennlighet, skalerbarhet, brukervennlighet, tilgjengelighet, robusthet, feil-toleranse etc etc. (går ofte under samlebetegnelsen “-ilities” på engelsk) Enkelte av disse vil ha påvirkning på brukergensesnittet, men vil også typisk stille krav til design og arkitektur, valg av rammeverk og hardware.
Hvordan håndtere dette?
For det første er dette er område som krever tett og godt samarbeid mellom forretningssiden og utviklerne. Og det fordrer reell tverrfaglighet i utviklingsteamet. Alle slike krav vil koste innsats og enkelte også investeringer. Derfor blir også dette en kost/nytte vurdering – som faktisk må gjøres løpende. De første produktinkrementene skal kanskje først og fremst validere antagelser rundt verdiforslaget og vil derfor godt kunne ha svak robusthet og mangle feiltoleranse. Det er liten vits i å lage et bunnsolid, feil-tolerant (og dermed dyrt) produkt som løser feil problem.
Hvor i Scrum adresseres dette?
Som nevnt må dette adresseres tverrfaglig, i Scrum i tett samarbeid mellom Product Owner og utviklerne. Mens de funksjonelle kravene enkelt resulterer i Product Backlog elementer, vil de ikke-funksjonelle måtte håndteres med ulike strategier. Vi må her ta i bruk det totale rammeverket.
Visjonen
Det starter med den langsiktige visjonen (som ikke er definert inn i rammeverket – men som bør være på plass). Hvordan ser suksess ut om 2-5 år? Går vi for “verdensherredømme” eller nøyer vi oss med en liten nisje? Hvor viktig kommer vekst og skalerbarhet til å bli for suksess? Skal vi inn i et marked med strenge regulatoriske krav? Kan liv og helse stå på spill med dette produktet? Skal vi konkurrere på brukervennlighet? Hvilke kompatebilitetskrav er det?
Produktmål
For å oppnå visjonen må vi nå en serie med produktmål. Et produktmål har gjerne en tidshorisont på mellom 3 måneder og et år. En Product Owner må gjerne definere en serie med produktmål som da vil fungere som en Road Map for produktet. Hvert av disse må være tydelig på ikke-funksjonelle krav. Hva er hovedhensikten med dette målet? Hvilke brukere adresserer det og hvilke krav vil denne brukergruppa sette til produktet? Vil rask responstid og høy ytelse være avgjørende for disse menneskene? Er vi avhengige av gamle softwarekomponenter, må vi ta med i betraktning om disse har teknisk gjeld må betales ned som en del av jobben. Vil de arkitekturprinsippene softwaren er basert på skalere godt nok, eller må vi gjøre om?
Product Backlog
Ikke-funksjonelle krav vil ofte ende opp som konkrete elementer i Product Backlog. De må da priorities på vanlig måte opp mot andre elementer, både av den funksjonelle og den ikke-funksjonelle typen. Dette er krevende, for her må man avveie tekniske egenskaper som ikke er synlig på overflaten mot synlig funksjonalitet som kan ha en mer åpenbar forretningsmessig verdi. Her er det ekstremt viktig at Product Owner og utviklerne har et tett, tillitsfullt og godt samarbeid.
Sprintmål
For å realisere neste Produktmål gjennomfører vi en serie med Sprinter med formål å oppnå Sprintmål. Disse baserer seg på valgte elementer i Product Backlog. Enkelte ikke-funksjonelle krav vil resultere i Product Backlog elementer som da skal prioriteres inn av Product Owner. Andre kan være vanskelig å knytte til spesifikke funksjoner. Ting som sikkerhetskrav, gode sanntidsegenskaper og høy ytelse kan være verdt å gjøre til en generelt prinsipp. Det kan i så fall gjøres til en del av Definition of Done.
Definisjon av Ferdig
Man kan se på Definisjon av Ferdig (Definition of Done) som en sjekkliste for det kvalitetssikrende arbeidet et produktinkrement skal ha gjennomgått. Alle punktene representerer arbeid, som vil ta tid, og som da definerer det kvalitetsnivået utviklerne mener de trenger for å ende opp med et godt produkt uten for mye feil og teknisk gjeld. Mao, der det ikke-funksjonelle har en generisk karakter og skaper en ramme for “alt vi gjør”. Hvis sikkerhet er kritisk for suksess, vil de da typisk legge til gjennomkjøring av en egen sikkerhetstest for å kunne si at noe er “Ferdig”. Hvis de sliter med teknisk gjeld, stiller de krav til at man “rydder i gammel kode” som en del av jobben.