Monthly Archives: August 2009

Notes on XP — No.2: The basic problem is ‘Risk’

How does XP deal with the problem of Risk in software development?

No deadline fails

          <= Only highest functionalities are implemented            

          <= It’s easy to finish small problems and small tasks in a short cycle of releases and iterations,

Project will not be canceled. <= Smallest release that makes the most biz sense will be implemented at first.

The system will not go sour <= A quality baseline supported by a suite of tests will make sure everything is fine at any moment.

Bug Free  <= System Test +  Unit Test

No Requirements misunderstanding <= Customer will be involved throughout the full cycle

Requirement Changes will not be horrible <= The change is limited in short release cycle so it cannot be huge.

Less talent drain and less impact of talent drain

         <= They are not frustrated by impossible tasks because they are responsible for the estimation of their own efforts.

         <= The work will be fun because they will less lonely

         <= New team members are gradually taking more and more responsibility so that it will not be a disaster if old members leave.


What is XP ?

XP is a light-weight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.

It promises to

1.Reduce project risk

2.Improve responsiveness

3.Improve Productivity

4.Add Fun

What are they?

   1.Pair Programming

   2.Unit Testing


   4.The simplest thing that could possibly work

   5.Metaphor(Refine the arch all the time)

   6.Continuous Integration

   7.Planning game(Make iterations really short)


很多需求文档过于简单,一个功能点只是一个谓词,而没有足够的发散。比如 "if A then B",那么 "if not A "该怎么办呢? 文档里没写,开发暂时悬搁。

需求分析员也是人,他可能不喜欢发散性思维,也可能太多发散让他很疲惫;反正最终结果就是需求发散不足,即完备性不足;所以我们就应该让机器来替它发散。这种机器就是一种软件,它读取简单的判断句作为输入,然后对这句话的各点进行各种维度的发散,导出各种各样的"what if", 以实现需求的完备性。 比如 if A  –> if not A, 就是一个例子。

那么可以在哪些维度上发散呢? 发散时可否可以利用相关上下文? 这种软件是否具有自适应的智能性?最后一点,这种软件如何实现?


  a. 布尔发散。 A -> Not A, A & B -> A || B 等等

  b. 数量发散。 A 关联 B。是一对多,多对一,还是多对多呢?

  c. 生命周期发散。比如 A关联或者依赖B。那么A被增删改时,B应该怎么办?反之如何?

  c. …




  一开始我们肯定想不到所有的发散规则,我们甚至会觉得很难表达某种规则。那么,能否让机器在工作的过程中自己来学习和进化? 比如说,我们对机器某次发散的程度很不满意,于是我们就自己补充了一些发散结果,并把它告诉机器;那么,再遇到类似的情况时,机器还会继续让我们失望吗? 这也是一个有意思的课题。