敏捷软件开发和极限编程介绍

《敏捷软件开发和极限编程介绍》由会员分享，可在线阅读，更多相关《敏捷软件开发和极限编程介绍（16页珍藏版）》请在金锄头文库上搜索。

1、敏捷软件开发和极限编程介绍0. 软件开发的本质先让我们看看一般的产品生产： 例一，汽车生产。原材料、配件等采购完毕（我这里说到了采购配件，这相当于把部分功能的生产转交给其他职能公司。对应到软件生产的(子) 项目外包。这个话题在本文就不扩展了） ，进入生产、组装、测试车间，进行一系列规定的工作流程。正常情况下，如果不发生不可抗拒的事件，那么可以按时完成合同规定的交付。这中间不会有什么变动性和不可预测性。例二，再来看一个例子，比如某人想盖一栋房子，他想使用环保材料，当开发商给出房子的草图、价格预算，交给他时，他可能会改变主意。在建造房子的过程中，他的一些想法会逐渐明朗化。当房子盖好之后，实物呈现在

2、他眼前时，原先他的那套装修想法也可能根据房子的实际样子来做调整，比如厨房的布局、主卧的装潢等。总的来说，事先的计划遇上了变化，站在“客户至上”的位置上，开发商业就要改变计划，满足客户的新需要。至于如何操作，那是合同谈判的事。客户改变想法是有理由的，因为原先那一套东西都是构筑在设计中的（纸质设计图，有的开发上会提供 3D 图形或动画） ，客户直到见到实物，才会有他进一步的，更明确的想法。软件开发是也生产性的行业，他的产品是交付给客户的软件。类比上面的例子，软件开发更接近于建筑行业，需求会变动，每次生产的东西都不太一样，甚至大不一样。更例外的一点，软件开发的工作量和时间估计比建筑生产更具备不确定性

3、。这种不确定性来自于需求变动、资金支持、技术风险、人员流动、质量控制、功能范围的确定等。（另外，一般来说通常客户只能规定四个变量 “代价、时间、质量、范围”中的三个，另外一个就是开发团队来选择了，比如客户准备花$XXX 在这个月底实现所有功能点；那么在压力下，质量的选择就是开发团队来确定了；否则就得调整客户选择的其他三个变量。这四个变量之说来自拥抱变化 ，极限编程的开山之作。 ）总的来说，软件生产的本质是具备创新性的新产品开发。新产品开发有那些特征呢？ 不可能在前期创建一成不变的、详细的规格说明。 在开始阶段，很难进行预期分析。随着经验数据的出现，计划与估算的可能性才会相应增加。 在开始阶段，

4、识别、定义、调度、和安排所有的细节活动都是不太可能的。通过构建反馈周期，可以推动自适应步骤。 一般情况是主动适应没有定义的变动，并且改动率比较高。与创新性新产品开发对应的就是具备可预见性的制造。它可以有笨重的前期规格说明、估算、推测计划等。而新产品开发拒绝这些“可靠的”前期规格说明，理由是： 客户或者用户不可能明确知道他们到底要什么。 （需要通过逐步的交流和引导让其明确起来） 他们很难陈述所有的需求和知识。 他们想要的许多细节只能在开发过程中逐步展现出来。 细节对于他们可能过于复杂。 当他们看到了产品的开发，他们将可能会改变初衷。 外部压力（比如竞争者的产品或者服务）导致需求的变更或者增加。1

5、. 近年来软件项目的一些统计数据以及一般性结论正是因为软件开发不是循规蹈矩的可预见性的生产活动，而是具创新性的新产品开发活动，所以很多采用遵循可预见性产品生产方式的软件项目最终都以失败收场，不管是小企业还是知名企业。这是新产品开发肯定会有的情况，当然也有方法论的问题。让我们来看一组软件开发领域的研究和统计数据，这些数据显示了近年来软件项目开发的基本情况：图 1.显示了一个对 23,000 个项目“成功实施持续时间”的关系，这里的“成功”定义为“项目在资金预算和项目工期内完成，并具备所有预先指定的特征和功能” 。（Standish98 Jim Johnson, et al. 1998. ChAO

6、S: A Recipe for Success, 1998. Published Report. The Standish Group） （大家可以用这个定义来衡量一下自己公司的项目成功率如何。 ）图 1. 项目成功率和项目持续时间的关系图 （横坐标为项目持续时间(多少个月 )；纵坐标是项目成功的比率）从这个图中，我们可以看出项目持续时间短的成功率比较高。可见小型项目易于成功。另外也有研究表明小团队的项目更易于获得成功。图 2. 显示了软件项目开展过程中增加进来的变动性因素的情况。项目大小以功能点来衡量，在图中对应横坐标；纵坐标表示需求的变动，仍以功能点为单位。(Jones97 Jones,

7、C. 1997. Applied Software Measurement. McGraw Hill)图 2. 需求变更和项目大小之间的关系图从这个图中我们可以看出需求变动无法规避，典型地，一个项目肯定要面对需求变更的情况，犹如前面的盖房例子。需求变更也影响到项目的成功率。 （这里的成功依旧遵从前面的定义。 ）图 3. 是需求管理中的要求实现的功能点在软件产品交付之后实际被使用情况的比率，这个比率非常惊人地表明几乎一半的功能甚至从为被使用过，相当多一部分功能也很少被使用。在竞争性产品市场上，这些功能点可能是卖点，从而也增加了项目的体积、复杂性，影响到项目的成功率，交付日期。非竞争性领域，对这些

8、需求应该再考虑考虑:-）按 20-80原则，20%的功能具备了产品的 80%的重要内容)（Johnson02 Johnson, J. 2002. Keynote speech, XP 2002, Sardinia, Italy.） 。另外，基于风险和客户驱动，可以最大化最常使用的功能。从而一个项目甚至在完成了其 20%功能时，就可以成为一个较为有用的阶段性发布。图 3. 产品中要求的功能点在实际中的使用情况另外，有证据显示，随着功能点的增多，每个开发人员的生产效率下降，每个开发人员的错误率上升。 （Jones00 Jones, C. 2000. Software Assessments, Be

9、nchmarks, and Best Practices. Addison-Wesley） 。此外有证据显示失败项目中很大一部分是采用瀑布模型的。2. 瀑布模型 vs. 迭代模型有什么样的世界观，就会有什么样的方法论。宇宙万物变动不居。没有绝对的静止。软件项目的实施过程同样如此。需求的变动，资金投入的变化、团队人员进出、质量范围改变、时间期限变更等之间都有一系列联动关系。应对变动性产生了截然相反的两种态度。通过分阶段的确定输入、输出来规避变动性，先确认输入是固定不变的（经评审的） ，这样就可以设计产生想要的下一个输出。这就是所谓“推(Push)”方式，这种方式似乎规避了变动性，注意，我们先前的

10、图 2. 说过即便是需求功能点变更也是常有的情况，所以对这种变动性的认识和响应实际上是被推迟到了项目的后期客户验收阶段。另外一种态度就是积极响应这种变动性，项目开展的整个过程中都鼓励加入新的需求这种方式。如果忽略许多争论不休的地方，大体上，试图规避或者说想一步到位获取需求的线性开发方式就是对应到“瀑布模型（Waterfall Model） ”，而积极响应变化的通过多次反复的增量式过程就是“迭代模型（Interative Model） ”。有必要说明一点，瀑布模型的发明者本人说他是迭代模型的拥护着，它只是认为瀑布模型是软件开发中的最简单的一种模型。我们来看一些图，直观地看一下这两种模型。图 4.

11、 是瀑布模型及其高风险示图，从这个图中我们可以看到随着时间的延续，风险增大。恐或正是因为早期的低风险，才使得人们在很长一段时间内喜欢采用这种模型。害怕风险是人类的通病。并且这种模型很简单，一个单调的过程，容易记忆，操作起来也很简单。需求-设计-实现- 测试。图 4. 瀑布模型及其高风险示图随着越来越多的证据证明了瀑布模型的高风险和高失败率之后，瀑布模型自身也发生了一些变化，以致继续有人采用这种模型的变体来进行项目开发。正如我以前写过的一个文档，这个模型一般来说不适合于是软件开发上。图 5. 是瀑布模型随着时间的推移，新加入变动性因素（比如需求变更等）的总体代价关系。图 5. 瀑布模型的变动性的

12、总体代价这种模型的一个重要问题就是缺乏反馈。他是一种通过单向的控制来完成的，并且相信这种控制都正确的，比如从 ANALYSIS DESIGN 这个过程，根据分析的决议来做设计，并且相信这个 ANALYSIS 是正确的。这类似于行军打仗，每个上级都认为他的指令被正确的执行，这种指令的正确性暂且不谈(这涉及到每层的控制人员的专业素养) ，显然会出现将在外军令有所不受的情况，或者失之毫厘，谬以千里。它的控制流程是 Push 式的，一层层往下推，如图 6.这里只截取了其中一个部分。图 6. Push 模式中的一个片段学过控制理论的人都知道一个最简单的道理， “没有反馈(feedback)，就没有控制”

13、 。反馈的基本原理就是把输出反馈给输入，如果偏差很大，就得调整控制过程，最终使得输出满足输入的需求。总体上看，软件开发的输入是客户，输出是软件产品，控制过程是软件项目的开发过程。如果只是一次性地把软件产品交付给客户，显然就是没有反馈。其过程是线形的： “客户 项目实施 客户”这样一个过程，风险很大，所以应该与客户协作，多进行几此这样的过程，让整个开发过程自适应化，最终交付成功得产品。如图 7.所示：图 7. 有反馈的，自适应过程图 7.的过程，在项目开发过程中，就是多次的迭代。每个迭代过程都是具体而微的 “需求-设计-实现-测试”单调过程。正是这样的多次迭代，降低了最终交付产品时的风险。让我们

14、看看迭代过程，下图：图 8. 迭代过程示意图每个迭代过程都是具体而微的“需求-设计- 实现-测试” ，通过这样多次的小步迭代，逐渐构筑成一个完整的系统。如图 9.多次的迭代，系统增量式地完善起来。图 9. 多次迭代，系统增量式完善起来随着时间的推移，每次迭代的重点又有所不同，图 8.中我们可以看出，早期迭代过程中，需求的比重大，中期则是设计和实现的比重增大。测试是始终比较重要的环节:-)。测试从始至终地控制着质量，降低风险。下图显示了瀑布型测试和迭代型测试的对比。每次迭代，完成客户要求的优先级别高的风险大的功能点（对应到 user-stories） 。每次确定 user-stories 的时候

15、都允许加入新的需求，一旦确定了下一个迭代过程要实现的 user-stories 列表之后，直到这个迭代过程结束，都不允许变动这个列表。顺便说一下，所有user-stories 的列表就是最终功能测试和验收测试的依据。User-sotiry 不同于 user-case，简单说，可以将 user-story 看成是 user-case 的描述部分，便于编写。而细节则在每次迭代的迭代设计阶段细化规格，再简单地设计，刚够满足应用就行。复杂的设计会有很多问题哦，做集体项目，并不是让你表现代码技巧的时候。图 10. 迭代过程中引入变化的总体成本走势每次迭代开始都欢迎加入新的需求变化，这样，就逐步的减小了产

16、品完成时候的风险，迭代模型对于变化的总体成本示意图如图 10.所示。多次迭代的一个好处就是能更准确的估算时间。不建立原型，光是纸上谈兵，很难准确的确定项目的工期/工时和工作量 (人月)。所谓原型，可以是抛弃式或非抛弃式的，这种原型的目的除了是验证架构性信息获取正确之外，也可以用来争取客户，获得中标的机会。更重要的是，可以用于估算项目工作量和时间，因为就你的团队，对这个塑造原型的前几次迭代所完成的功能点数量，就可以大致地推断你的团队的生产效率和持续前进的速度。从而把握好如何确定项目的时间。这里有一个图显示了估算项目时间的不确定性：图 11.初期迭代之后才能大致估算时间进度表另外：可以研究一下敏捷迭代开发-管理者指南上提到的如何签定两阶段合同的问题：如果我是甲方，我就会在第一阶段让准备竞标的各公司给出我的需求的一个原型（可以是草图的）