{"id":825,"date":"2019-02-21T18:24:52","date_gmt":"2019-02-21T17:24:52","guid":{"rendered":"https:\/\/agilerasmus.com\/wordpress\/?p=825"},"modified":"2019-02-28T12:04:47","modified_gmt":"2019-02-28T11:04:47","slug":"lovkrav-og-scrum-kan-det-lade-sig-gore","status":"publish","type":"post","link":"https:\/\/agilerasmus.com\/wordpress\/lovkrav-og-scrum-kan-det-lade-sig-gore\/","title":{"rendered":"Lovkrav og Scrum – kan det lade sig g\u00f8re?"},"content":{"rendered":"\n
I en agil organisation hvor Scrum er det b\u00e6rende element for teamene kan det v\u00e6re sv\u00e6rt at h\u00e5ndtere store opgaver som f.eks. lovkrav vedtaget af Folketinget, EU eller andre instanser. En rygmarvsreaktion kan v\u00e6re at s\u00e6tte den iterative og inkrementelle udvikling p\u00e5 pause og begive sig ud i en l\u00e6ngerevarende analyse som udm\u00f8nter sig i en detaljeret nedbrydning af opgaven. Det er ikke \u00f8nskv\u00e6rdigt – hverken for den agile organisation eller for det enkelte teammedlem som ender med at bygge til lager frem for til produktion.<\/p>\n\n\n
Udfordringen kan naturligvis l\u00f8ses. Gitte Kaalund, afdelingsleder i Bankdata, udtalte:<\/p>\n\n\n
\n
Det vigtigste n\u00e5r man l\u00f8ser et lovkrav er at se det som et forl\u00f8b hvor man l\u00f8bende tilf\u00f8rer funktionalitet til systemerne samtidig med v\u00e6rdi til brugerne og ikke som \u00e9n stor samlet leverance ved udl\u00f8b af deadline<\/p>\n<\/blockquote>\n\n\n
\u00c9n m\u00e5de at h\u00e5ndtere lovkrav med Scrum er at opdele lovkravene i spiselige bidder. Det kan g\u00f8res p\u00e5 mange m\u00e5der. Nedenfor er \u00c9n m\u00e5de at g\u00f8re det p\u00e5:<\/p>\n\n\n
\n
Skab overblik<\/li>\n
Definer form\u00e5l, benefit og m\u00e5l<\/li>\n
Rang\u00e9r tema, epics og enabler<\/li>\n
Behandl epics og enabler epics<\/li>\n
Ranger feature og enablers<\/li>\n
Nedbryd features og enablers i stories<\/li>\n<\/ol>\n\n\n
Skab overblik<\/h1>\n\n\n<\/figure>\n\n\n
Tidligt i processen skabes et overblik over hvilke temaer, epics og enabler der ber\u00f8res i lovgivningen. Dette er f\u00f8rste bud p\u00e5 hvilket omfang opgaven har.<\/p>\n\n\n
Et tema er en overordnet gruppering i lovkravet og kan f.eks. v\u00e6re “Retningslinjer for afl\u00f8nningspolitik og -praksis i forbindelse med salg og levering af detailbankprodukter og -tjenester.” fra boligkreditdirektivet. Temaet driver den \u00e6ndring der skal skabes i system og produkt for at indfri lovkravet.<\/p>\n\n\n
En epic er en ligeledes en gruppering, dog p\u00e5 mere l\u00f8sningsn\u00e6rt niveau, men abstrakt nok til at kunne arbejde inkrementelt med MVP iterationer. Eksempler p\u00e5 epics er “Adgang til at ud\u00f8ve virksomhed som kreditinstitut og om tilsyn med kreditinstitutter og investeringsselskaber”, “Forbrugerkreditaftaler i forbindelse med fast ejendom til beboelse”, “Betalingstjenester i det indre marked” og “Adgang til at optage og ud\u00f8ve virksomhed som udsteder af elektroniske penge og tilsyn med en s\u00e5dan virksomhed.”.<\/p>\n\n\n
En enabler er en underst\u00f8ttende gruppering der prim\u00e6rt bruges til at udbygge og forberede systemarkitekturen s\u00e5 de identificerede epics kan leveres.<\/p>\n\n\n
Definer form\u00e5l, benefit og m\u00e5l<\/h1>\n\n\n
De identificerede temaer, epics og enablers beskrives alle med form\u00e5l, benefit og m\u00e5l der b\u00e5de er med til at afgr\u00e6nse opgaven men samtidig ogs\u00e5 med til at kommunikere opgaven til de involverede.<\/p>\n\n\n
Form\u00e5let beskriver hvilke kunder der er i m\u00e5lgruppen og hvilket behov de \u00f8nsker at f\u00e5 d\u00e6kket. Benefit angiver hvilke kvantitative og kvalitative forbedringer m\u00e5lgruppen kan forvente hvis form\u00e5let bliver indfriet. M\u00e5l angiver hvilke l\u00f8bende m\u00e5linger der kan foretages p\u00e5 “outcome” for at verificere at l\u00f8sningen er p\u00e5 rette spor.<\/p>\n\n\n
Ranger temaer, epics og enabler<\/h1>\n\n\n
Uafh\u00e6ngige temaer rangereres over for hinanden ligesom epics og enablers rangeres indbyrdes overfor hinanden. F\u00e6lles for de forskellige typer er at de alle rangeres efter forventede omkostning ved en eventuel forsinkelse. Det er essentielt at fokusere p\u00e5 at minimere risiko i forbindelse med udvikling af lovkrav. Ikke alle lovkrav skal indfries samtidig; visse har en mindre omkostning forbundet med forsinkelse end andre. Det kan v\u00e6re sv\u00e6rt at kvantificere omkostninger forbundet med forsinkelse pr\u00e6cist, hvorfor det ofte anbefales at g\u00f8re det relativt f.eks. med business value poker kort eller tilsvarende.<\/p>\n\n\n
Behandl epics og enabler epics<\/h1>\n\n\n
De involverede teams og deres Product Owners har nu en indikator for hvilken r\u00e6kkef\u00f8lge de b\u00f8r behandle lovkravene. \u00c9n efter \u00e9n nedbrydes de i features og enablers der kan l\u00f8ses p\u00e5 maksimum 2-3 m\u00e5neders sigt og har beskrevet med form\u00e5l, benefit og form\u00e5l. Det kan v\u00e6re v\u00e6rdifuldt at identificere fremtidige features og enablers, men undlad at g\u00e5 for meget i detalje med epics og enablers der ligger ude i fremtiden.<\/p>\n\n\n
Ranger feature og enablers<\/h1>\n\n\n
P\u00e5 samme vis som temaer, epics og enabler rangeres de nedbrudte features og enablers efter omkostning ved forsinkelse. Det er typisk lettere at kvantificere omkostningen p\u00e5 de nedbrudte elementer, da denne kan beregnes som en fraktion af det overordnede tal.<\/p>\n\n\n
Nedbryd features og enablers i stories<\/h1>\n\n\n
Teamet kan nu planl\u00e6gge og nedbryde features og enablers i rangeret orden s\u00e5 de individuelt kan v\u00e6re i et sprint og samlet udg\u00f8r f\u00f8rste iterative inkrement p\u00e5 featuren eller enableren.<\/p>\n\n\n
Ja, lovkrav og Scrum kan godt lade sig g\u00f8re!<\/h1>\n\n\n
At arbejde iterativt og inkrementelt med lovkrav indeb\u00e6rer en naturlig risiko, da man ofte er n\u00f8dt til at udvikle software i parallel med at lovteksten bliver godkendt. Det g\u00f8r at man antager at f\u00f8rste iteration af en feature ogs\u00e5 kan anvendes n\u00e5r den endelige lovtekst bliver godkendt. Det er naturligvis en risiko som kan h\u00e5ndteres \u2013 f.eks. ved inddragelse af eksperter og brugere.<\/p>\n\n\n
Det kr\u00e6ver et st\u00e6rkt setup med et stabilt udviklingsteam, erfaren Product Owner og erfaren Scrum Master. Til sammen skal de sikre at relevante interessenter giver input og at processen i forhold til at arbejde inkrementelt og iterativt bliver efterlevet. Opn\u00e5r man det, s\u00e5 f\u00e5r man et helt team der kommer t\u00e6ttere p\u00e5 hinanden fagligt og socialt samtidig med at f\u00f8ler at deres erfaring og kompetencer kommer i spil p\u00e5 rette vis!<\/p>\n\n\n
![\"\"](\"https:\/\/i1.wp.com\/agilerasmus.com\/wordpress\/wp-content\/uploads\/2019\/02\/FeatureMap.png?fit=1019%2C1024&ssl=1\")
<\/figure>\n\n\n