Något som jag har tyckt har varit irriterande under en längre tid är hur vanligt det är för många i branschen att använda termer som ”Scrum men …” i en pejorativ bemärkelse, vilket innebär att team endast bör följa den lilla uppsättning metoder som ingår i Scrum. Verkligheten är att Scrum i sig självt inte räcker för att ett agilt team ska kunna leverera fungerande mjukvara över en längre tidsperiod. Vare sig de inser det eller inte, arbetar de allra flesta team som kallar sig Scrum-team som en Scrum-XP-hybrid, eller en Scrum-Kanban-XP-hybrid, där de använder åtminstone en delmängd av de tekniska metoder som har sitt ursprung i XP.
Låt mig säga att team som bara följer Scrum-praktikerna troligen inte kommer att bli framgångsrika på lång sikt, eftersom åtminstone en delmängd av de tekniska XP-praktikerna är ett måste för att lyckas som ett agilt leveransteam.
Jag har observerat att det inte finns tillräckligt många människor som förstår vad Scrum innefattar och inte innefattar, så låt oss börja där.
Vad Scrum är – en uppsättning ledningsrutiner
Scrum är tillämpningen av empirisk processkontroll, vilket är ett fint sätt att säga att vi bör fatta beslut som grundar sig på erfarenhet, och inte på någon hypotetisk uppsättning antaganden som inte har någon grund i verkligheten.
Simpelt uttryckt består Scrum av en liten uppsättning ledningsrutiner som är avsedda att hjälpa team att samarbeta effektivt och leverera arbete på ett iterativt sätt (låt mig än en gång betona – det finns inga tekniska rutiner i Scrum).
För att kortfattat sammanfatta innehållet i Scrum-guiden:
- Det finns ett Scrum-team, som består av utvecklare, produktägaren och Scrum Master.
- Det finns Scrum-händelser, som består av Sprint, Sprintplanering, Daily Scrum (även kallad Daily Standup i XP), Sprint Review och Sprint Retrospective.
- Det finns Scrum-artefakter som består av Product Backlog, Sprint Backlog och Increment, där en Increment existerar så snart ett objekt från Sprint Backlog uppfyller definitionen av Done.
- Det finns en definition av Done, där alla Scrum-team har en gemensam förståelse av vad ”done” innebär för varje Product Backlog-objekt. Observera att i motsats till Acceptance Criteria tillämpas Definition of Done globalt, medan Acceptance Criteria är specifika för enskilda Product Backlog Items.
Vad Scrum inte är
I motsats till vad många tror är ingen av följande saker en del av Scrum:
- User stories. Arbetsmomenten i ett givet Scrum-teams Product Backlog eller Sprint Backlog skrivs som användarberättelser (ofta i formatet ”As a <persona/role>, I want <goal>, so that <desired outcome>”), men Scrum föreskriver inte någon särskild konstruktion eller något särskilt format. Observera att user stories är en del av XP.
- Uppskattning. Även om den stora majoriteten av Scrum-teamen gör uppskattningar på någon nivå, är uppskattningspraxis inte en del av Scrum.
- Velocity. Hastighet är inte heller en del av Scrum; begreppet projekthastighet är en del av XP.
- Tekniska metoder. Som nämnts ovan finns det inget begrepp om tekniska metoder (CI, CD, parprogrammering, TDD osv.) i Scrum. Den stora majoriteten av de tekniska metoder som teamen vanligtvis följer har sitt ursprung i XP.
Vad är Extreme Programming?
Det har gått mer än två decennier sedan det första Extreme Programming-teamet (XP-teamet) bildades, där man arbetade med ett projekt som kallades Chrysler Comprehensive Compensation (C3). De metoder som teamet använde sig av härstammade till stor del från 1980-talet, då Kent Beck och många andra experimenterade med bättre sätt att utveckla mjukvara, dvs. ett alternativ till den ”vattenfallsmetod” som hade blivit dominerande vid den tiden.
Att göra arbetet visuellt har alltid varit ett viktigt sätt att informera om hur agila team arbetar. Som en introduktion till XP rekommenderar jag därför att alla som vill lära sig mer skulle vara betjänta av att börja med dessa diagram:
- Extreme Programming Project (end-to-end diagram)
- Iteration (diagram som fokuserar på vad som händer i en iteration; observera att det som XP kallar en iteration konceptuellt sett liknar det som Scrum kallar en Sprint)
- Development (diagram som fokuserar på interaktioner och aktiviteter inom utveckling)
- Collective Code Ownership (diagram som fokuserar på de centrala tekniska metoderna)
Note: För en visuell bild som kombinerar många av elementen från diagrammen ovan på en sida, se Bill Wake’s Extreme Programming Overview.
Övrig läsning om XP
Om de visuella bilderna ovan fascinerar dig tillräckligt mycket för att du ska vilja läsa mer om XP, se följande informationskällor, som är listade mer eller mindre i ordning från kortast att läsa > längst att läsa:
- Don Wells, Extreme Programming: a gentle introduction
- Martin Fowler, BeckDesignRules (se även Xp Simplicity Rules)
- Kent Beck, Ward Cunningham, et al., Extreme Programming Core Practices (aka the 12 XpXtudes)
- Don Wells, The Rules of Extreme Programming
- Ward Cunningham, et al.,Extreme Programming (aka the WikiWikiWeb)
- Ron Jeffries, What is Extreme Programming?
- Kent Beck & Cynthia Andres, Extreme Programming Explained: Embrace Change (2nd Ed.)
Andra referenser
Alla referenser i det här avsnittet kommer från Don Wells XP-webbplats, om inget annat anges.
- Agila modeller är målningar, inte fotografier (alla modeller är fel; some are useful)
- Agile Process Proverbs (ord som alla team kan leva efter)
- Bill Wake, Arrange, Act, Assert (mönster för att skriva enhetstester)
- Bill Wake, Sudoku Solver (intressant variant på TDD)
- Bill Wake, Tests from a Hat (ett kreativt tillvägagångssätt för att skriva enhetstester)
- Ärliga planer (hur uppskattning ser ut i praktiken)
- Manage Your Goals Instead of Activities (huvudskillnader mellan vattenfalls- och agil utveckling)
- The Values of Extreme Programming (Simplicity, Communication, Feedback, Respect, Courage)
- XP och databaser (ett mönster baserat på guld > silver > bronsdatabaser )