Noget, som jeg har fundet irriterende i et stykke tid, er, hvor almindeligt det er for mange i branchen at bruge udtryk som “Scrum men …” i en nedværdigende betydning, hvilket antyder, at teams kun bør følge det lille sæt af praksisser, der er en del af Scrum. Virkeligheden er, at Scrum i sig selv ikke er nok, hvis et agilt team skal være i stand til gentagne gange at levere fungerende software over en længere periode. Uanset om de er klar over det eller ej, fungerer langt de fleste hold, der kalder sig Scrum-teams, som en Scrum-XP-hybrid eller en Scrum-Kanban-XP-hybrid, hvor de anvender i det mindste en delmængde af de tekniske praksisser, der stammer fra XP.
Lad mig slå fast, at hold, der kun følger Scrum-praksisserne, sandsynligvis ikke vil få succes på lang sigt, fordi i det mindste en delmængde af de tekniske XP-praksisser er et must for vedvarende succes som et agilt leveringshold.
Jeg har observeret, at der ikke er nok mennesker, der forstår, hvad Scrum omfatter og ikke omfatter, så lad os starte der.
Hvad Scrum er – et sæt ledelsespraksisser
Scrum er anvendelsen af empirisk processtyring, hvilket er en finere måde at sige, at vi bør træffe beslutninger baseret på erfaring og ikke baseret på et eller andet hypotetisk sæt af antagelser, der ikke er forankret i virkeligheden.
Simpelt sagt består Scrum af et lille sæt ledelsespraksisser, der har til formål at hjælpe teams med at samarbejde effektivt og levere arbejde på en iterativ måde (lad mig endnu en gang understrege – der er nul tekniske praksisser i Scrum).
For kort at opsummere indholdet af Scrum-guiden:
- Der er et Scrum-team, som består af udviklere, Product Owner og Scrum Master.
- Der er Scrum-hændelser, som består af Sprint, Sprint-planlægning, Daily Scrum (aka Daily Standup, i XP), Sprint Review og Sprint Retrospective.
- Der er Scrum-artefakter, som består af Product Backlog, Sprint Backlog og Increment, hvor et Increment eksisterer, så snart et element fra Sprint Backlog opfylder definitionen af færdig.
- Der er en definition af færdig, hvor ethvert Scrum-team har en fælles forståelse af, hvad “færdig” betyder for ethvert Product Backlog-element. Bemærk, at i modsætning til Acceptance Criteria anvendes Definition of Done globalt, mens Acceptance Criteria er specifikke for individuelle Product Backlog Items.
Hvad Scrum ikke er
I modsætning til hvad mange tror, er ingen af følgende ting en del af Scrum:
- Brugerhistorier. Arbejdsemnerne i et givet Scrum-teams Product Backlog eller Sprint Backlog skrives som brugerhistorier (ofte i formatet “Som <person/rolle> vil jeg have <mål>, så <det <ønskede resultat>”), men Scrum foreskriver ikke nogen bestemt konstruktion eller format. Bemærk, at brugerhistorier er en del af XP.
- Estimering. Selv om langt de fleste Scrum-teams udfører estimering på et eller andet niveau, er praksis med estimering ikke en del af Scrum.
- Velocity. Velocity er heller ikke en del af Scrum; begrebet projekthastighed er en del af XP.
- Teknisk praksis. Som nævnt ovenfor findes der ikke noget begreb om teknisk praksis (CI, CD, parprogrammering, TDD osv.) i Scrum. Langt de fleste af de tekniske praksisser, som teams typisk følger, stammer fra XP.
Hvad er Extreme Programming?
Det er mere end to årtier siden, at det første Extreme Programming (XP)-team blev dannet, hvor de arbejdede på et projekt kaldet Chrysler Comprehensive Compensation (C3). De metoder, som det hold anvendte, stammer i høj grad fra 1980’erne, hvor Kent Beck og mange andre eksperimenterede med bedre måder at udvikle software på, dvs. et alternativ til den “vandfaldsmetode”, der var blevet dominerende på det tidspunkt.
Det at gøre arbejdet visuelt har altid været en vigtig måde at informere om, hvordan agile teams arbejder. Derfor anbefaler jeg som en introduktion til XP, at alle, der ønsker at lære mere, vil være godt tjent med at starte med disse diagrammer:
- Extreme Programming Project (end-to-end diagram)
- Iteration (diagram med fokus på, hvad der foregår inden for en iteration; bemærk, at det XP kalder en iteration konceptuelt set svarer til det, Scrum kalder en Sprint)
- Development (diagram med fokus på udviklingsinteraktioner og -aktiviteter)
- Collective Code Ownership (diagram med fokus på de centrale tekniske praksisser)
Note: For et visuelt billede, der kombinerer mange af elementerne fra ovenstående diagrammer på én side, se Bill Wake’s Extreme Programming Overview.
Der er yderligere læsning om XP
Hvis ovenstående visualiseringer fascinerer dig så meget, at du har lyst til at læse mere om XP, kan du se følgende informationskilder, som er listet mere eller mindre i rækkefølge efter kortest at læse > længst at læse:
- Don Wells, Extreme Programming: a gentle introduction
- Martin Fowler, BeckDesignRules (se også Xp Simplicity Rules)
- Kent Beck, Ward Cunningham, et al., Extreme Programming Core Practices (aka de 12 XpXtudes)
- Don Wells, The Rules of Extreme Programming
- Ward Cunningham, et al.,Extreme Programming (aka WikiWikiWeb)
- Ron Jeffries, What is Extreme Programming?
- Kent Beck & Cynthia Andres, Extreme Programming Explained: Embrace Change (2nd Ed.)
Udviduelle referencer
Alle referencer i dette afsnit er fra Don Wells’ XP-hjemmeside, medmindre andet er angivet.
- Agile modeller er malerier, ikke fotografier (alle modeller er forkerte; nogle er nyttige)
- Agile Process Proverbs (ord, som ethvert team kan leve efter)
- Bill Wake, Arrange, Act, Assert (mønster til at skrive enhedstests)
- Bill Wake, Sudoku Solver (interessant variation på TDD)
- Bill Wake, Tests from a Hat (en kreativ tilgang til at skrive unit tests)
- Honest Plans (hvordan estimering ser ud i praksis)
- Manage Your Goals Instead of Activities (hovedforskelle mellem vandfald og agil udvikling)
- The Values of Extreme Programming (Simplicity, Kommunikation, Feedback, Respekt, Mod)
- XP og databaser (et mønster baseret på guld > sølv > bronze databaser )