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?

   1.
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,

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

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

   4.
Bug Free  <= System Test +  Unit Test

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

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

   7.
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

   3.Refactoring

   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, 就是一个例子。

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

1.发散维度

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

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

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

  c. …

2.相关上下文

  大多数谓词并不是孤立的。它们有互相依赖关系。一个谓词的发散,可能会导致许多相关谓词的发散;同样,在试图对一个谓词进行发散时,也可以利用相关谓词作为先验知识,以组合出更多的发散维度。那么,如何表达这种相关关系?具体的触发算法如何?

3.自适应性

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

4.如何写这种软件?

  我不知道这个怎么写。但有个大前提是,要么用某种形式化的语言来写需求,要么对所使用的自然语言采取严格的约束,使它终究可以被机器理解。