敏捷工程实践：超越Scrum仪式

当工程实践支持方法论时，敏捷才能发挥作用。

极限编程（XP）核心实践

持续集成

# CI runs on every commit to main
# Never let main stay broken
on:
  push:
    branches: [main, 'feature/**']

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - run: npm test
      - run: npm run build
    # Build must stay under 10 minutes

测试自动化

// Automated test pyramid:
// Many unit tests (fast, isolated)
// Some integration tests (medium speed)
// Few E2E tests (slow but critical paths)

// Target: 80% code coverage
// But coverage is a floor, not a ceiling

结对编程

Driver: writes code
Navigator: reviews, thinks ahead, asks questions

Benefits:
- Knowledge sharing
- Fewer bugs (two pairs of eyes)
- Better design (talking through it)
- No bus factor (knowledge shared)

Practical:
- Switch roles every 30 minutes
- Use VS Code Live Share or Tuple
- Remote pairing works too

可持续节奏

Anti-patterns:
- Heroic sprints (unsustainable overtime)
- Technical debt accumulation under pressure
- Skipping tests when "behind"

Better approach:
- Consistent velocity over time
- Protect time for tech debt reduction
- No overtime as a normal practice
- "Yesterday's weather" for planning

故事拆分

INVEST criteria for user stories:
Independent - can be deployed alone
Negotiable - details can be discussed
Valuable - delivers user/business value
Estimable - team can estimate it
Small - completable in 1-2 days
Testable - clear acceptance criteria

Vertical slicing (good):
"User can log in with email and see their dashboard"
= tiny end-to-end slice

Horizontal slicing (bad):
"Build the database layer for authentication"
= no user value on its own

完成的定义

![敏捷工程实践：超越Scrum仪式 插图](https://images.pexels.com/photos/4792721/pexels-photo-4792721.jpeg?auto=compress&cs=tinysrgb&h=650&w=940)

## 完成的定义

A user story is done when:
- [ ] Code written and passing all tests
- [ ] Unit test coverage >= 80%
- [ ] Code reviewed and approved
- [ ] Acceptance criteria met (manual verification)
- [ ] Deployed to staging environment
- [ ] No new critical/high security vulnerabilities
- [ ] Documentation updated (if API changed)
- [ ] Product owner accepted

Sprint回顾

What worked well?
- Celebrate successes

What didn't work?
- Problems encountered

What will we do differently?
- ONE specific action item per retro
- Assign owner and due date

Review last retro's action items first

重要的度量指标

Lead time: commit to production (hours, not weeks)
Deployment frequency: how often you can deploy safely
Change failure rate: % of deployments causing incidents
Mean time to recovery: how fast you fix incidents

These DORA metrics correlate strongly with team performance.

当工程实践与流程一样强大时，敏捷才能成功。