Ordbog

Når man taler om teknologier som kunstig intelligens og process mining, kommer man ikke udenom at bruge forskellige fagtermer fra blandt andet data- og informationsvidenskaben. Derfor har vi lavet denne ordbog, der indeholder fagtermer og udtryk, man kan støde på her på hjemmesiden. 

Agile

  • Agile dækker over forskellige værdier, mønstre, principper og metoder, der understøtter en omstillingsparat tilgang, når man f.eks. arbejder med projekter, hvor der er hyppige forandringer, fragmentarisk viden og turbulens. (ScrumMaster.dk: Agile på 60 sekunder

Algoritme 

  • En algoritme er en række klart definerede instruktioner for, hvordan f.eks. en computer eller en AI skal løse et problem – lave udregninger, analysere/behandle data, vælge retning osv. (Wikipedia: Algorithm) 

Big Data

  • Indsamling, lagring/opbevaring, analyse, bearbejdning og fortolkning af enorme mængder data. (Wikipedia: Big data)

Back-end

  • Den del af- og de processer i et program/software som brugeren typisk ikke ser, interagerer med eller har adgang til, som kører i baggrunden og er nødvendig for at programmet virker.

Data

  • Inden for IT er data formaliserede oplysninger, der kan behandles maskinelt. Dette kan forstås som information, der på den ene eller anden måde omdannes til tal, som kan bearbejdes af en computer. (Den store danske: Data)

Data Management

  • Data management beskriver en proces, hvori man indtager, opbevarer, organiserer og vedligeholder de data som er skabt og/eller samlet af en organisation. (Techtarget.com: Data management)

Data Science / Datavidenskab

Fail fast

  • 'Fail fast' er et design- og udviklingsprincip forbundet med en Agile tilgang til projekter. Denne tilgang handler om at være åben og modtagelig over for fejl, lære af dem (hvorfor nogle kalder det 'Learn fast' frem for 'Fail fast') frem for at lade sig slå ned af dem, samt at skynde sig at teste og fejle, så man kan finde frem til fejl eller svagheder inden man når for langt i sit projekt. Det knytter sig i bund og grund til at være iterativ, teste så meget som muligt, og ikke være bange for at teste for tidligt, da tidlige fejl kan være lærerige. (Elvenite: What fail fast really is - And why you should do it today)

Feedback / feedback system

  • Feedback kan forstås som respons, reaktioner, meninger m.fl. på f.eks. en test, en præsentation, en workshop, eller andet. Feedback er i denne optik respons på en afprøvning, som designer, udvikler eller anden kan bruge konstruktivt til at ændre, forbedre eller udvide det, der blev afprøvet. Feedback i en mere teknisk optik er et element i et system, som fodres nogle Input (tal, værdier, ord, meninger (anything)), gør noget med de Input og producere nogle Output (resultaterne af at systemet har kørt). Nogle af disse Output kan (afhængig af formålet) bruges som nye Input næste gang systemet skal køre. Disse Output, der omdannes til nye Input kaldes Feedback - de fodres tilbage til systemet. (Wikipedia: Feedback)

  • Feedback og feedback systemet kan anvendes og forstås meget teknisk - f.eks. knyttet til programmering, eller mere løst - f.eks. knyttet til én der afholder workshops. 

    • Eksempel 1: I programmering, kan man ofte anvende en funktion, der hedder et ‘feedback loop’. Du fodrer feedbackloopet (som er systemet) med f.eks. et tal, det tal kører så igennem en matematisk ligning og producerer et nyt tal, som så på ny køres igennem ligningen og producerer et nyt tal og så videre indtil man stopper loopet, eller det producerer en ønsket værdi. 
      • Input (første gang): et vilkårligt tal
      • System: en ligning, hvor Input indgår  
      • Output: Resultatet af ligningen 
      • Feedback: Resultatet af ligningen, som fordres ind i ligningen på ny
    •  Eksempel 2: Hvis du afholder en workshop, og løbende eller efterfølgende indsamler, hvad deltagerne kunne lide/ikke lide. Ros kan du så bruge til at vælge, hvad der skal holdes fast i ved næste workshop. Ris kan du tage med næste gang du planlægger eller udvikler på din workshop (denne plan og udvikling svarer til systemet, der bearbejder input), og næste gang du afholder din – nu forbedrede – workshop, hvor du igen indsamler ris og ros til næste Iteration. 
      • Input (første gang) - egen viden eller erfaringer
      • System - planlægning og eksekvering af workshop
      • Output - Ris og Ros
      • Feedback - Ris og Ros, som medtages som input næste gang du planlægger og eksekverer workshop. 

Front-end

  • Den del af et program/software som brugeren ser, har adgang til og kan interagere med på forskellig vis. Er ofte både grafisk og brugervenlig. 

GDPR

  • GDPR står for General Data Protection Regulation og er en lovgivning, som er indførst af EU, der handler om at sikre sine kunders og ansattes personoplysninger. (GDPR.dk Hvorfor efterleve GDPR?)

Iterativ proces

  • En iterativ proces beskriver en proces der er drevet af gentagelser og versionering. Ved hver gentagelse eller version opnås ny eller dybere indsigt i et problem. Ved brug af en ‘Trial-and-error' tilgang, gentages typisk en proces, hvor et produkt udvikles (version 01), produktet testes, feedback (resultat af test) indsamles, indsigter opnås, produkt (med nye indsigter) udvikles (version 02) - og så videre indtil man er tilfreds med produktet.(Retrospectives.dk: Agil og Iterativ)

Kunstig Intelligens (KI) / Artificial Intelligence (AI)

  • En computer eller et stykke software (et program), som efterligner et eller flere aspekter af den menneskelige intelligens som evnen til abstrakt tænkning, analyse, problemløsning, mønstergenkendelse, sprogbeherskelse og -forståelse, fornuftig handling. Da AI som udgangspunkt er dreven af en computer, kan AI ofte analysere, bearbejde og læne sig op ad utroligt store mængder data (Big Data). Kunstig intelligens er endvidere ofte forbundet med evnen til at kunne lære og tage til sig, omend der er tale om ny viden eller ny adfærd (se machine learning) (Den store danske: Kunstig intelligens)

Machine Learning

  • Machine learning hører under kunstig intelligens og beskriver hvordan en AI bruger bl.a. historiske data og 'egne' erfaringer fra handlinger, begivenheder og konsekvenser, til at lære hvad der er u/hensigtsmæssigt eller hvad der virker/ikke virker i en given situation. Jo flere data eller egne erfaringer den kan lære fra, jo mere præcis bliver den til den opgave, den skal udføre - om det er at komme med forslag til effektive indsatser, stoppe en proces den kan forudse er ved at køre af sporet, eller noget helt andet. (IBM: Machine learning)

Mockup

  • En Mockup er en model af et produkt, som man typisk bruger under design- og udviklingsfasen af et produkt, til at fremvise og afprøve udformning og basal funktionalitet. Formålet med en mockup er at man hurtigt og uden brug af signifikante ressourcer (hvoror en mockup f.eks. ofte laves af pap) kan afprøve en idé eller et koncept. (Wikipedia: Mockup)
  • Går man skridtet videre og inddragere væsentlig og vigtig funktionalitet i sin model kalder man det en Prototype.

Predictive Monitoring

  • En kombination af data mining (process mining), kunstig intelligens og machine learning. Ved at analysere historiske data kan en kunstig intelligens lære at forudse problemer eller hændelser i en given kontekst. Jo mere data AI'en har at arbejde med, jo mere præcise forudsigelser kan den lave. (Motadata: Predictive monitoring)

Process Mining

  • Process mining handler om at indhente relevant data fra processer eller forløb, med henblik på at gøre data til indsigt og handling. Process mining har til formål at belyse og identificere styrker og svagheder i forskellige dele af en proces. (Wikipedia: Process Mining)

Process Monitoring

  • Process monitoring er en systematisk og løbende overvågning og dokumentation af nøgleaspekter/nedslag i en proces / et forløb, for at vurdere om et forløb følger eller afviger fra forventningerne/standarterne. (Wikipedia: Process monitoring)

Prototype

  • En prototype er en meget tidlig udgave af et produkt under udvikling. Prototyper bruges bruges ofte i design- og udviklingsfasen af et produkt til at fremvise og/eller teste væsentlig og vigtig funktionalitet, som man ønsker i det endelige produkt. (Wikipedia: Prototype).
  • Prototyper kan have forskellige formål afhængig af hvor og hvor langt man er i udviklingen. Er man f.eks. meget tæt på at færdiggøre sit produkt, vil prototypen typisk være holistisk og tæt på det komplette produkt (kaldes også nogle gange version 0). Men befinder man sig tidligt i design- eller udviklingsfasen eller ønsker man at teste noget meget specifikt kan man lave prototyper med forskellig fokus og scope. Her taler man typisk om Horisontal- og Vertikal prototype. (Usability first: horizontal and vertical prototypes)
    • En horisontal prototype  fokuserer på at teste/fremvise produktet bredt - dvs. mange funktion, men uden at gå i dybden med de enkelte funktioner. Denne er god hvis man vil teste helheden af et produkt.
    • En vertikal prototype fokuserer på én eller få funktioner, for at gå i dybden med disse. Denne er god hvis man vil teste specifikke kernefunktioner grundigt.

Scrum

  • Scrum er et rammeværk (framework), der kan hjælpe folk, hold og organisationer til at få mest mulig værdi ud af komplekse opgaver, gennem fleksible og tilpasningsdygtige  løsninger. (The Scrum Guide)
  • Scrum gennemgås i detalje i afsnittet 'Scrum'

Software

  • Software sæt instruktioner, der fortæller computeren hvad den skal gøre. Dette sæt instruktioner kan til tider bestå af uendeligt mange siders kode og samlinger af forskellige koder. Software findes både i computerens styresystem (windows, MacOS, Linux) og styrer computerens interne functionalitet, men det findes også som eksterne applikationer og programmer, som man kan downloade og gøre til en del af computerens (eller telefonens) funktionalitet (f.eks. messenger, angry birds, ms365, photoshop osv.) (Britannica: Software)

Tale- og billedgenkendelse

  • Når et stykke software kan analysere og bearbejde data fra billeder eller lyd (både billed- og lydmateriale eksisterer som data i form af tal og koder, som en computer kan arbejde med), og genkende hvad et billede viser, eller hvad der bliver sagt. 

Working Software 

  • Working software bruges i Agile til at beskrive en funktionel mockup eller prototype, som man kan fremvise f.eks. ved slutningen af et Sprint, og kan vise resultatet af et sprint eller en specifik indsats. Fokus ligger på at vise hvad noget kan, eller hvor langt noget er, frem for at fortælle det (show don't tell). (Coveros.com: The Agile Manifesto Principles - Deliver Working Software)  

Scrum

Scrum er et rammeværk (framework), der kan hjælpe folk, hold og organisationer til at få mest mulig værdi ud af komplekse opgaver, gennem fleksible og tilpasningsdygtige løsninger (The Scrum Guide)

Da Scrum ikke nødvendigvis hører under kunstig intelligens og denne ordbog vil afklare flere begreber, der er scrum-specifikke, har Scrum fået sit eget afsnit her.

Omvendt Ordbogen, er dette afsnit ikke opdelt alfabetisk. Rækkefølgen er bestemt af, hvordan de forskellige begreber hører sammen, så læseren bedre kan forstå Scrum som helhed. 

(Scrum framework - Scrum.org: What is scrum?)

Scrum Theory

(The Scrum Guide: Scrum Theory)

  • Transparency 

    • I Scrum er det vigtigt at alle artifacts indeholder en høj grad af gennemsigtighed, så alle der arbejder med projektet samt dem, der skal modtage produktet og andre interessenter tydeligt forstår dem.
    • Lav gennemsigtighed leder til dårlige beslutninger og dalende værdi. Høj gennemsigtighed leder til effektiv Inspection.
  • Inspection

    • Scrum Artifacts og fremskridtet mod de mål, der er stillet skal inspiceres ofte og flittigt, for effektivt at fange uønskede problemer eller variationer. Inspection fordre Adaption og er derfor vigtigt i Scrum.
  • Adaption

    • I scrum-sammenhæng handler Adaption om at projektet skal kunne justeres, hvis aspekter af en proces eller resultatet af en proces bevæger sig uden for det acceptable. I Scrum - og generelt i Agile - er det centralt at anerkende at verden, viden, omstændigheder, krav m.fl. ændrer sig. Derfor skal et projekt også kunne tilpasse sig de ændringer. Adaption bliver nemmere og hurtigere, hvis et team er selvstyrende og autonome. 

Scrum Team

(The Scrum Guide: Scrum Team)

Scrum teames består af en Scrum Master, en Product Owner og flere Developers. Der er ingen underkategorier af hold og der er intet hierarki. Scrim teamet er multifunktionelt - de kan udføre alle relevante opgaver i projektet, og det er autonomt - der er ingen, der uddelegere opgaver til individer i teamet, eller bestemmer hvordan de skal udføre opgaverende mm. Hele teamet har ansvar og tager ansvar for at skabe værdi og Increments ved hvert Sprint.  

  • Developers

    • Developers er dem i teamet, der skaber alle aspekter af et brugbart Increment ved hvert Sprint. Developernes evner er ofte forskellige og typisk bestemt af arbejdsområdet/projektet. Developers er således ikke nødvendigvis udviklere/programmøre, men betegner alle der er med til at udføre opgaverne i et sprint. Alle developers er ansvarlige for at: 1) der bliver lavet et Sprint Backlog; 2) etablere og sikre kvalitet, der passer til Definition of Done; 3) tilpasse deres plan, hver dag, så den retter sig mod Sprint Goal; 4) stille hinanden til ansvar for sprintet.
  • Product Owner

    • Det er Product Ownerens (PO) ansvar at maksimere værdien af det produkt, som skabes af teamets arbejde. Derudover, er det også PO'ens ansvar at vedligeholde og organisere Product Backlog
    • Det er vigtigt at alle i organisationen respekterer PO'ens beslutninger i forhold til Product Backlog. Ønsker man noget i Product Backlog ændret eller tilføjet, skal man pverbevise PO'en. 
    • Ofte repræsenterer PO'en de mange forskellige interessenters behov og ønsker.
  • Scrum Master

    • Det er scrum masterens ansvar at etablere scrum og scrum praksis i organisationen. Dette gøres ved at sørge for at alle forstår scrum teori og praksis. Scrum masteren har ansvar for scrum teamets effektivitet. Scrum masteren faciliterer og sikre at scrum events bliver afholdt og at scrum teamet forstår scrum. 

Scrum Events

Scrum Events  beskriver faste praksisser og møder, som finder sted inden for et sprint. Scrum Events er fastlagte og gentages ved hvert sprint. Dette mindsker risikoen for spildt tid og unødvendige møder. De fastlagte events i scrum er hhv. Sprint, Sprint planning, Daily scrum, Sprint review og Sprint retrospective. 

(The Scrum Guide: Scrum Events) 

  • Sprint

    • Er en fastlagt periode på max. 1 måned, helst ca. 2 uger, hvori alle de andre events ligger. Et sprint starter med planlægning af sprintet og hvilke opgaver (items), der skal fra product backlog til sprint backlog, og slutter med sprint retrospective, hvor man ser tilbage på foregående sprint, hvad der gik godt, hvad der kunne gøres bedre i næste sprint mm. Et nyt sprint starter så snart det foregående er overstået.  
  • Sprint Planning

    • Ved Sprint planning mødes hele scrum teamet, med product owner og planlægger det kommende sprint. Her vælges items fra product backlog og overføres til sprint backlog.   
  • Daily Scrum

    • Daily scrum er et 15-minutters møde, som gerne holdes dagligt, og har til formål at undersøge og sikre sig at sprintet skrider frem mod at fuldende sprint goal. Hvis det viser sig at der af den eller den andet grund, er behov for at tilpasse sprint backlog, gøres det her. Med dette hyppige møde, mindskes behovet for andre møder. Det er Scrum masterens opgave at holde mødet og sikre sig at det bliver holdt inden for tidsrammen, men det er Developers der deltager i og bidrager til mødet. Det er deres møde.  
  • Sprint Review

    • Ved sprintets afslutning undersøges resultaterne af sprintet af scrum teamet, samt relevante interessenter i et sprint review. Her kan man evt. ændre i product backlog, mens man diskuter hvordan projektet forløber mod product goal. 
  • Sprint Retrospective

    • Under dette møde inspicerer scrum teamet, hvordan det foregående sprint er forløbet, hvad gik godt, hvilke problemer opstod der og hvordan blev de problemer løst (eller ikke løst). Dette gøres med henblik på forbedring og på at øge kvalitet og effektivitet ved næste sprint. 

Scrum Artifacts

Scrum Artifacts repræsenterer arbejde eller værdi. Artifakterne er til for at øge gennemsigtighed, så enhver kan forstå dem. 

(The Scrum Guide: Scrum Artifacts) 

  • Product Backlog

    • Product backlog er en prioriteret liste af opgaver (items), der er nødvendige at fuldføre for at komme i mål med projektet. Product backlog er emergent, og udvikler sig således løbende under projektets varighed – gennem tilføjelse, slettelse, forfining og/eller omprioritering af items. Items i backloggen skal være veldefineret, transparente og skal kunne gennemføres af Teamet i løbet af 1 sprint.  
    • Refinement 
      • Refinement handler om, særligt for product owneren, at nedbryde og specificere items, så et evt. for stort eller omfattende item bliver delt op i mindre præcise items.
  • Product Goal

    • Product Goal, er en fremtidig udgave af produktet, som Teamet tilstræber ved at fuldføre Items fra backlog. Det er det langsigtede mål for Teamet. 
  • Sprint Backlog

    • Sprint backlog er en liste af Items udvalgt fra product backlog, under en sprint planning event, som skal udføres i løbet af kommende sprint. Disse er også prioriteret og skal helst fuldføres i prioriteret rækkefølge. 
  • Sprint Goal

    • Sprint goal er målet for det enkelte sprint, som udførelse af items fra sprint backlog skal resultere i.
  • Increment

    • Increment beskriver den tilføjelse til produktet, der er under udvikling, som hvert sprint medfører. Hvert increment er et skridt nærmere Product Goal. Hvert increment skal helst virke sammen med tidligere increments, så alle versioner af produktet er brugbare. Ét sprint må gerne producere flere increments. Det eller de increments, der er udviklet i løbet af sprintet fremvises ved Sprint review. Increment følger typisk Working software-princippet. 
  • Definition of Done

    • Hvert item, i et backlog, skal indeholde en definition of done, der beskriver hvornår det specifikke item er fuldført. Når et item under udvikling møder kravene i itemets definition of done, er det et increment - en færdig tilføjelse til produktet.  
Process Mining