Hvad er Agile?

Fuldført

Vi brugte udtrykket agile i det forrige modul til at beskrive et af de væsentlige elementer i DevOps-kulturen, der repræsenterer muligheden for hurtigt at reagere på kundefeedback og -behov. Dette ord blev også vist flere gange i det undermodul, der beskriver korrelationen mellem DevOps og programmets livscyklus. Der er dog også en anden mere specifik betydning af Agile (i stort format), som beskriver en tilgang til softwareudvikling og projektstyring. En sådan tilgang er ofte knyttet til DevOps-fremgangsmåder. I vores eksempelscenarie vil overgangen fra den traditionelle vandfaldstilgang til Agile hjælpe organisationen med at realisere en række DevOps-fordele. I dette undermodul skal du udforske de primære egenskaber for Agile og undersøge korrelationen med DevOps.

Agile principper og værdier

Agile er en tilgang til softwareudvikling, der fremmer teamsamarbejde, løbende forbedringer og automatisering med det ultimative mål om hurtigere, mere pålidelig og kundecentreret softwarelevering. Udtrykket stammer fra Det Agile Manifesto, der blev oprettet i 2001 af en gruppe softwareudviklere, hvilket giver et sæt vejledende principper for moderne softwareudvikling. Manifestet indeholdt fire grundlæggende udsagn, der prioriterede enkeltpersoner og interaktioner, arbejdsløsninger og kundesamarbejde over stive processer og værktøjer. Disse sætninger tildelte især mere værdi til:

• Enkeltpersoner og interaktioner over processer og værktøjer.
• Arbejder software over omfattende dokumentation.
• Kundesamarbejde i forbindelse med kontraktforhandlinger.
• Svarer på ændring i løbet af at følge en plan.

Agile metoder og praksisser

Agile Manifesto- og Agile-principperne giver et sæt værdier og retningslinjer, men de er bevidst ikke præskriptive med hensyn til specifikke metoder og praksisser. Agile er i stedet beregnet til at være fleksibel og let at tilpasse, så organisationer og teams kan vælge en mere detaljeret tilgang i henhold til deres præferencer og behov.

Disse detaljerede, omfattende tilgange kaldes ofte for rammer. Deres formål er at dække alle faser i DevOps-livscyklussen, herunder planlægning, udvikling, levering og drift. Nogle af de mere populære agile strukturer omfatter Scrum og Kanban.

Hvad er Scrum?

Scrum er en struktur, der bruges af teams til at administrere arbejde og løse problemer i samarbejde på kort (typisk mellem en og fire uger lang) gentagelser kaldet sprints. For at lette samarbejde og fremskridt er sprints struktureret på baggrund af hændelser, artefakter og roller.

• Begivenheder, der ofte kaldes ceremonier, omfatter møder, der finder sted dagligt (Daily Scrum, typisk begrænset til 15 minutter, også kendt som daglig standup) og i begyndelsen og slutningen af hver sprint (Sprint Planlægning, Sprint Review og Sprint Retrospective).
• Artefakter definere en prioriteret liste over funktioner, forbedringer og rettelser, der skal udvikles. Sådanne artefakter kan dække rækkevidden af et projekt eller en sprint (henholdsvis Product Backlog eller Sprint Backlog), eller de kan hjælpe Daglige Scrum-møder (opgaveforummer og sprint burndown-diagrammer). En opgavetavle giver en visuel måde at spore status for hvert element i restloggen på. Der vises elementer i restloggen opdelt i de opgaver, der kræves for at fuldføre den. Opgaver placeres i separate kolonner (navngivet At gøre, Igangværendeog Udført) baseret på deres status. Sprint-burndown-diagrammet fungerer som en visuel indikator for, om teamet er på vej til at fuldføre sit tildelte arbejde ved slutningen af sprinten. Den består af en graf, der viser det daglige samlede resterende arbejde, som typisk vises i timer.
• roller omfatte produktejeren, Scrum-masteren og Scrum-teamet, der hver især har sit klart definerede ansvar. Produktejeren repræsenterer projektets interessenter og er ansvarlig for at definere, vedligeholde og prioritere produktefterslæbet. Scrum-masteren fører tilsyn med Scrum-processen, leder efter områder til forbedringer, løser eventuelle blokeringsproblemer og sikrer, at Scrum-principperne følges. Scrum-teamet er ansvarlig for at bygge produktet med ejerskab af dets tekniske og kvalitetskomponenter.

I sprintplanlægningsbegivenheden vælger teamet, at der skal arbejdes på efterslæb i løbet af den kommende sprint. Valget foretages på baggrund af prioritet og en anslået arbejdsmængde, der kræves for at fuldføre en vare. Metrikværdien kaldet hastighed bruges til at måle, hvor meget arbejde et team kan udføre i en given sprint. Når sprintudførelsen starter, beslutter teamet, hvordan de skal arbejde med Sprint Backlog-elementerne. Under Sprint gennemgang, viser holdet deres resultater til interessenter. Sprint retrospektiv er en del af kontinuerlig læring. Det tjener som mulighed for at gennemgå den senest fuldførte sprint, identificere områder til forbedring og hjælpe med at bestemme listen over handlinger til den næste sprint.

Hvad er Kanban?

Kanban er det japanske ord for et skilt eller en skiltetavle. I forbindelse med Agile er begrebet Kanban tænkt som et middel til at forbedre effektiviteten af produktionsprocesser, men i de senere år blev det udbredt i softwareudviklingsprojekter.

Hovedprincippet i denne tilgang er visualisering af projektrelateret arbejde i form af Kanban-tavler. Det kan være fysiske tavler eller softwareprogrammer, der viser kort, der er arrangeret i kolonner, der repræsenterer status for individuelle projektelementer. Ofte anvendte kolonnenavne omfatter opgave, Gørog Udført, selvom teams kan tilpasse dem, så de afspejler alle relevante faser i en arbejdsproces til projektlevering (f.eks. udvikling og test). Visualisering af arbejde som kort i forskellige stater på et board forenkler vurderingen af projektets status og identificerer potentielle produktivitetsproblemer.

Disse kort svarer til produkters efterslæb i Scrum-strukturen. Kortene kan tilpasses, så de indeholder referencer til andre elementer i produktleveringsprocessen, f.eks. opgaver og testcases.

Selvom begrebet restlog er almindeligt i Kanban og Scrum, er det vigtigt at bemærke, at Kanban er mere fleksibel og ikke involverer gentagelser. Arbejdselementer kan tilføjes, omprioriteres eller fjernes fra efterslæbet baseret på teamets kapacitet og de ændrede behov for det projekt eller den tjeneste, der administreres med Kanban.

Kanban fremmer især brugen af en pullmodel, hvor interessenter føjer anmodninger til listen over opgaver, elementer eller arbejde, der skal fuldføres. Udviklingsteamet vælger elementer fra restloggen og føjer dem til den aktive arbejdsproces afhængigt af deres prioritet og teamets ressourcers tilgængelighed. Dette minimerer de kvalitetsproblemer, der er knyttet til pull-modellen, hvor interessenter vilkårligt tildeler arbejde til udviklingsteams, ofte med urealistiske deadlines. For at optimere produktiviteten understøtter Kanban desuden, at der pålægges begrænsninger for antallet af elementer, som udviklingsteamet arbejder på i øjeblikket, kaldet igangværende arbejde eller blot WIP-.

Kanban-struktur er også afhængig af gennemløbstid og cyklustid målepunkter for at måle effektiviteten og gennemløbet af arbejdsprocessen. Gennemløbstid er den samlede tid, det tager for et arbejdselement at skifte fra start til levering til kunden. Cyklustid repræsenterer varigheden af det faktiske arbejde på et element, når det er trukket ind i den aktive arbejdstilstand.

En anden almindeligt brugt komponent i Kanban er et CFD-(akkumuleret flowdiagram). Det er et diagram, der illustrerer antallet af elementer i hver tilstand over tid, typisk på tværs af flere uger. Det ligner et stablet tidsseriediagram, hvor den vandrette akse repræsenterer tidslinjen og den lodrette akse, der repræsenterer det akkumulerede antal arbejdselementer. Hver tilstand vises som et forskelligt farvet område, hvilket gør det nemmere at identificere tendenser i behandlingen af elementer i efterslæb. En forøgelse af størrelsen på et eller flere farvede områder angiver typisk et problem i arbejdsprocessen, f.eks. en flaskehals eller ineffektivitet.

Hvad er forskellen mellem Scrum og Kanban?

Både Scrum og Kanban anses for at være Agile frameworks med det fælles mål at forbedre effektiviteten og effektiviteten af softwareudvikling. Men hver af dem tilbyder en anden tilgang til at nå dette mål, herunder deres respektive principper og praksis. Især:

• arbejdsrytme: Scrum bruger sprints med fast længde, mens Kanban fungerer baseret på en kontinuerlig flowmodel, hvor arbejde trækkes af udviklingsteams i henhold til tilgængeligheden af deres ressourcer.
• Roller og ceremonier: Scrum har klart definerede roller og ceremonier, mens Kanban ikke foreskriver nogen, i stedet for at tillade teams at tilpasse disse i henhold til deres specifikke behov.
• Arbejdsplanlægning: Scrum bruger en prioriteret efterslæb med arbejde, der er forpligtet til under sprintplanlægning. Kanban bruger en dynamisk efterslæb uden forpligtelser for en bestemt periode. Desuden understøtter Kanban begrebet WIP-grænser.
• tilpasningsevne til at ændre: Scrum fraråder ændringer af engageret arbejde under sprinten. Kanban faciliterer tilpasning til ændringer når som helst.
• Visualiseringer: Scrum bruger sprintboards og burndown-diagrammer. Kanban er afhængig af Kanban-tavler.
• Metrikværdier: Scrum bruger sprintrelaterede målepunkter, f.eks. hastigheds- og burndown-diagrammer. Kanban lægger vægt på sådanne målepunkter som gennemløbstid og cyklustid.