应用Key Conception进行敏捷软件开发

前几天在公司听了一个老外的讲座，内容和标题一样，是应用Key Conception进行敏捷软件开发，感觉有所收获，拿出来共享一下。在开始一个Project的时候，首先要解决的两个问题是：“这个项目要实现哪些特性”和“哪些特性要优先完成，哪些可以稍后完成”。因为我们不解决这两个问题，整个项目的开展就会变得十分混乱，把时间消耗在确定“下一步要做什么”，“Oh no，现在看起来其实当初应该先弄好那个特性”这样的事情上。正因为通过主管臆断很可能会导致错误的决定，所以我们需要一个更有效的工具来帮助我们解决这两个问题。

如果我们用Feature List来表示“要实现的特性”，用优先级来表示这些特性被完成的顺序，实际上我们可以通过下面这样一张表来帮助我们对项目更好地进行规划：

Feature\Key Conception	KC(1)	KC(2)	…...	KC(n)	SUM
Feature-1
Feature-2
….
Feature-n

介绍一下什么是Key Conception[以后简称KC]，我觉得或许叫Key Target更合适一些，意指达成项目目标的关键因素或影响项目最终质量的关键条件。一个项目当然会有多个这样的KC，他们是影响项目所要实现的特性及其优先顺序的关键因素。下面我们就以手机QZone项目为例，说明如何利用这张表来帮助我们确定本文开始所要解决的那两个问题。

这是一个将互联网QZone的功能搬到手机端的项目，我们认为该项目的KC有：图像质量，UI体验感，下载速度[其实还有很多，为简便暂时只列3条]。要实现的特性就太多了，这里也只列一部分：

(1)用Flash完成酷炫的效果；

(2)只用一个按钮完成所有操作；

(3)Context Sensitive功能[即通过软件当前状态的Context就能判断用户当前操作的意图]

(4)按需下载主题[即不是一次性地、而是根据需要下载相应的主题数据]

等等…...

填表的规则是：如果某个特性特别有利于某个KC，那么给2分，一般有利1分，没啥关系0分，起反作用-1分，特别不利于该KC就给-2分。最后计算一下每一行的总分，就可以明确到底应该做那些事情，以及这些事情的先后顺序了。我们的例子填完之后如下[仅供参考]：

Feature\Key Conception	图像质量	UI体验感	下载速度	SUM
用Flash完成酷炫效果	2	0	-2	0
只用一个按键完成全部操作	0	1	0	1
Context Sensitive功能	0	2	0	2
按需下载主题	-1	0	2	1

稍微解释一下，对于第一行来说，如果用Flash的话，当然效果很炫。但是对于手机来说是一大考验，因为现在无线的下载速度实在不敢恭维，可能你东西还没下载一半用户已经不耐烦了，所以是这样一个分数。对于第二行，由于手机客户端千奇百怪，一个软件要想兼收并蓄支持绝大多数手机，就必须精简操作，使用更少的按键完成尽可能多的操作，所以第二个Feature是符合用户使用利益的，但和其他两个KC无甚关联。OK，至此我们就可以根据最终的分值来决定到底哪些特性应该被有限执行，特别是当你的特性列表有几百个的时候。而且这种方法还可以减少因为过分依赖直观感觉而产生错误决定的几率。因为这些分值所对应的是Key Conception，所以决定的顺序是客观的、考虑周全的、符合项目整体目标和利益的。

虽然这里里的例子十分简单，但并不代表真正操作起来也会如此轻松，因为世界是多样的，问题层出不穷，用这样一个简单的表有时无法完全达到目的，这时就必须做一些调整来适应我们的需求。例如，我们都知道，项目中的每一个特性其实现难度都是不同的，难度有时也是决定某个特性优先级的关键因素，于是我们就需要在标的最后加上一列用以记录每一个Feature的难度。

Feature\Key Conception	KC(1)	KC(2)	......	KC(n)	SUN	Difficulty
Feature-1
Feature-2
….
Feature-n

在最终确定顺序的时候，经验的原则是在同等分数的Features中，优先做哪些困难的部分，如此才会有顺流而下或猛虎下山的气势。先挑简单的后作困难的可能会影响团队的士气，在项目总不断地勇攀高峰有时并不明智。此外，每一个KC可能也有不同的重要性，所以在打分的时候可以对不同的KC加以不同的优先权重来体现其重要程度，这也会对总分产生影响。不过应该尽量不要搞的过于复杂，因为“过犹不及”。

另一个例子是，对于一个大项目，我们的Feature List可能有数百条，把这些都搞到一张表里容易被湮没在特性海洋中不能自拔，殊为不智。这时候我们可以给出一个Outline Feature List，用于摆放那些关键的、抽象一些的特性，利用这个纲领性的表来首先决定一个大体的范围。然后在进行每一项细化的操作的时候，再针对每一个抽象的Feature列出一个Detail Feature List，这样作既简单又清晰，从此不必为过长的特性列表发愁了。

Outline Feature List[OFL]

Feature\Key Conception	KC(1)	…...	KC(n)	SUM	Difficulty	Detailed Feature List
Feature-1						DFL[1]这里的每一项都是与OFL同样格式的表，只是目的和内容不同
….						DFL[2]
Feature-n						DFL[n]

除此之外，还有很多可以讨论的问题，在实际工作中我们可以灵活地对这个表进行调整，赋予新的结构和新的含义来适应实际项目需要，但是一个重要的原则是不要太过复杂，这个度就需要自己把握了。

内容就到这里吧，不过投诉一下CSDN的Blog，在写Blog和预览的时候表格是好好的，可是一发布网页上的结果就是自动在每段前加了缩进，使得表格格式都乱了，希望解决一下。