[INF43] Lecture 17 Process part 3

软件工程 SoftwareEngineering


@ZYX 写于2020年06月09日

XP Model

  1. Always create tests as early as possible, especially before coding
  2. Do as many development activities in pairs as possible
  3. Test as often as possible(continuous testing)
  4. Refactor all code
    • 改善代码质量,但不改变代码功能
  5. Involve the customer as much as possible


  1. Open space office
  2. All pair programming
  3. 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
  • Follow values and principles


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