Ordbog

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.

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.

En vedhæftet tilføjelse til en skriftlig aftale.

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.

Indsamling, lagring/opbevaring, analyse, bearbejdning og fortolkning af enorme mængder data.

Business intelligence dækker en række softwareløsninger, der har til opgave at overskueliggøre og simplificere data fra forskellige kilder i en organisation, ved at transformere dem til noget enklere og sætte dem ind i en ny database, hvor slutbrugeren kan tilgå dem. Herfra kan de nemt anvendes i bl.a. statistik og rapportering. Bi bruges således til at skabe overblik og tilgængeliggøre en organisations myriader af data.

En chatbot er et stykke software som simulerer menneskelig samtale gennem tekst- eller stemmeinteraktioner.

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.

Data lakes er et sted hvor der opbevares store mængder, ustrukturerede data, i sin rå tilstand (dvs. en tilstand som typisk ikke kan læses af mennesker). Dette betyder at der kan opbevares meget store mængder data, som ikke fylder lige så meget, som havde de været struktureret og oversat til noget læseligt.

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

Datavidenskab handler om at finde indsigt igennem analyse og bearbejdning af data.

Decision science beskriver teknikker, der bruges til at informere individder og grupper i deres beslutningstagning.

'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.

• 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
• 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.

Flådestyring, også kaldet fleet management, er en generel betegnelse for, hvordan man bevarer overblikket og optimerer den daglige drift af en organisations biler, varevogne, lastbiler, maskiner, busser, mm.

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 står for General Data Protection Regulation og er en lovgivning, som er indført af EU, der handler om at sikre sine kunders og ansattes personoplysninger.

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.

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).

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.

Metadata er data om data. Det vil sige, data der knytter sig til eller giver uddybende information om andet data. Et eksempel kunne være, hvis man har data over, hvilke biler man har til rådighed i en kommune. Metadata her kunne være information om hvilket år, hver bil er fra, hvornår de hver skal til service, hvornår de sidst er blevet tanket eller opladt osv.

• 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. 
• Går man skridtet videre og inddragere væsentlig og vigtig funktionalitet i sin model kalder man det en Prototype.

”Partnerskab for Offentlige Grønne Indkøb (POGI) er et fællesskab af kommuner, regioner og offentlige organisationer, der vil fremme bæredygtige løsninger og købe grønt ind.”

• 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.
  • 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 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.

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

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.

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.

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.

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.)

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 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).