XP Model
- Always create tests as early as possible, especially before coding
- Do as many development activities in pairs as possible
- Test as often as possible(continuous testing)
- Refactor all code
- 改善代码质量,但不改变代码功能
- Involve the customer as much as possible
其他特征
- Open space office
- All pair programming
- every one has to learn code standard
- then they can communicate effectively
VS traditional waterfall
More “extreme” reaction to waterfall and other heavyweight/traditional processes, which usually have:
- Lengthy development times
- Inability to cope with changing requirements
- Assumption that requirements are completely understood before the project begins
- Too much reliance on heroic development effort
- Complex methodology
- Waste/duplication of effort
XP Practices and Principles
- Whole team
- Small releases
- Customer tests
- Simple design
- Pair programming
- Test-driven development
- Design improvement
- Continuous integration
- Collective code ownership
- Coding standards
- Metaphor
- 用故事描述设计 — 沟通
- Sustainable pace/developer welfare
- Open space
- Shared understanding
- Rapid, fine feedback
XP Process Steps
- Determine the desired features (stories)
- Estimate, prioritize, refine
- Implement/deliver each task
- Typically using…
- Test-driven development
- Pair programming
- Typically using…
- Follow values and principles
Agile
From XP to Agile
- Agile includes and evolved from
- Extreme Programming, Scrum, Crystal, Kanban, others
- The Agile Manifesto (2001)
- “We have come to value…”
- Individuals and interactions
- Over processes and tools
- Working software
- Over comprehensive documentation
- Customer collaboration
- Over contract negotiation
- Responding to change
- Over following a plan
Some Agile Principles
Welcome change in requirements
Business people and developers work together daily throughout the project
Build projects around motivated individuals
Face-to-face conversation is the best way to convey information
Documentation is just a means to an end
Continuous delivery
Agile Strengths/Weaknesses
- Strengths
- Customer (and developer) satisfaction
- Adaptable to changing circumstances
- Good for projects with unclear, changing requirements
- Good for small teams
- Weaknesses
- Lack of documentation
- Unstable requirements
- Technical debt
- Original agile ideas not ideal for projects with large teams / safety critical requirements / projects in which customer involvement is not possible