3)　第二步做什么，系统反馈什么
4)

…

　

5)　问题解决了，结束本故事
我们会仔细的看这些故事，发现有些地方看不懂，于是我们就去问清楚，有些事情是
那个描述故事的 A 也不清楚的，但 A 告诉我们 B 会懂，于是我就问 B；有些事情 A 也
不知道有谁会知道，我们就把它放在一边，等知道的时候再问，继续看其他的故事。
2.　了解系统隐喻，构造软件框架。永远也问不清楚所有的事情，所以当我们知道整个
系统的是为了解决什么问题，将用什么办法来解决它（暂时叫做系统隐喻），关键人
物也认可时，我们就不再问下去了。我们依据这个系统隐喻去构造一个最上面的故事。
然后，只关心与这个故事有关的故事。同时构造一个程序框架以支持项目的开发
3.

…

　实现故事。在软件框架上，实现一个故事，再实现一个故事，

4.　实现变更。有时发现事情并没有想象的简单，于是就变更它，这就要求我们实现这

…

些次变更。它象实现故事一样：实现一次变更，再实现一次变更，
5.　部署软件。感觉软件已达到了可被接受的预想或合适的要求了，就发布这个软件。
上面所说的故事就是我们常说的用例（use　case）。我们可以使用用例的形式来描述
整个系统的计划内容，并计算它的工作量，为工作之间、项目之间的绩效提供一个统一
的衡量标准。
这时，我们发现：
1.　由故事（有些项目可以用故事所包含的步骤）的数量可计算出开发的工作量
2.　我们实际开发工作过程的时间、成本、进度是可以被不了解项目实现技术的人所感知
的
如果我们仔细查看项目的所有工作，会发现有些工作不是基于某个用例的，也与某些
用例没有直接关系，如何拿用例来计算它的工作量呢？在项目的开发中确定存在这些
工作，如项目开始时的"了解软件项目的故事"。但通过分析知道，在一个软件项目中顶
层用例的数量是不难预测的，也是说在这个时期要向关键人了解的用例数是可以预测
的。我们不难发现，要了解的用例数越多，需求了解的工作量就越大。在相同类型的应
用软件开发中，需求了解的工作量与用例数量的比例是基本一致的。同理，了解系统隐
喻，构造软件框架、部署软件的工作量与用例的量也是成比例的。
在没有不熟习技术的前提下，根据本人的经验，同类软件项目的工期与底层用例数
（更多信息请参考"http://www.leadge.com/publish/html/14215.html"）或步骤数有着可
计算的关系，如 WEB 应用软件中，一个底层故事的开发时间大约为 1.5 个人日。这个
是经验数据，在不同的公司可能有所不同。网上也有文章证明不同规模的应用软件，故
事与程序代码的行数有一定的计算关系。这样我们的不同项目，或同一项目的不同故事
之间，在时间、成本、进度上就具有了可比性。
同时，我们发现项目的进度、成本的估算可以通过简易的公式进行一次性计算得到

解决方法
可以使用用例（use　case）来计算项目的进度、成本，如果使用这个计算结果作为考
核的依据的评分标准，将可以很好的完成绩效考核。它的作法是：
1.　对要做的项目进度评估，确定其可能拥有的用例数，并用这个用例数计算进度、成