敏捷方法与经典软工较量.docVIP

敏捷方法与经典软工较量 　　“在IT领域，我们正好都在从装备统治一切的时代走出来。现在我们正进入一个唯有灵活性才是至关重要的时代。”Tom DeMarco在为《规划极限编程》一书所做的序中曾将软件开发方法的变迁历史比作人类的军事发展史。在序中，他援引卡尔?冯?克劳塞维茨在《战争论》中的观点，认为军事历史就是一个在装备和灵活性的相对优势之间来回摇摆的钟摆:从古罗马的重装步兵，到中世纪的骑士，再到成吉思汗的轻骑兵，及至一次大战中的坦克与现代战争中的反坦克导弹。每一个新兵种或新武器的诞生，都代表着某种相对性优势:或装备，或灵活性，二者不断的交替轮回。 　　而在仅有短短数十年历史的IT行业，人们也经历了类似的变迁。早期手工作坊式的软件开发模式铸就了无数个人英雄与他们的传奇故事，此时灵活性的优势彰显无疑。而随着软件复杂度的逐步提升与人们对软件期望值的愈加膨胀，仅凭一己之力的手工作坊已然不再适合。人们迫切需要有方法论的指导，以应对多人协作的开发模式。 　　于是，各种软件开发方法纷至沓来，软件工程作为一门学科，也逐渐进入了平常人的视野，装备的优势初现端倪。然而在经历过从理论到实践的洗礼之后，人们却发现一度被当作济世良药的方法学并未在所有领域都如人所愿:在许多普通的软件企业里，一些在没有方法学指导时就存在的问题，依旧顽固的存在着。为了摆脱困境，人们增加了更多约束行为和思想的条规，并要求提供更多除软件本身以外的东西。这样的做法使软件组织投入了更多的成本，在降低了开发效率的同时，却并未达到预期的效果:进度延期，成本超支，质量低劣，客户关系僵化，团队士气低落……装备的优势地位受到了质疑。在这样一个时代背景之下，强调以灵活性见长的敏捷方法应运而生，其标志便是2001年敏捷联盟的成立与敏捷宣言的诞生。 　　 　　敏捷方法的两大焦点:适应性与人 　　 　　敏捷方法的两大主要特征便是对“适应性”的强调与对“人”的关注。关于这一点，Martin Fowler在他的《新方法学》一文中有过专门的论述。 　　经典的软件工程方法借鉴了建筑工程领域的实践，它强调前期的设计与规划，并尝试在很长时间跨度内为一个软件开发项目制定严格而详尽的计划，然后交由具备普通技能的人群分阶段依序达成目标。这方面的代表就是早在1970由Winston Royce提出的“瀑布模型”，直到上个世纪80年代早期，瀑布模型一直都是唯一被广泛采用的软件开发模型。但是这样的做法在面对变化的需求与外部环境时，却并不能发挥其应有的效力:由于前后相继的线性开发模式使得人们只有在每个阶段的末尾才能见到成熟的制品，因此一旦产生变更，尤其是在软件生命周期的后期，就会导致严重的后果。与此同时，在我们所处的环境中，很多时候需求的变更都属于常态。 　　敏捷方法强调对变化的快速响应能力，它通过引入迭代式的开发手段，较好的解决了如何应对变化的问题。这里要指出的是，“迭代”并非是一个新生概念，以迭代为特征的开发方法由来已久，只是名称叫法有所不同。例如:由Barry Boehm在1988年提出的“螺旋模型”便是一种具备鲜明的迭代特征的软件开发模式。 　　 　　图：经典的瀑布模型 　　 　　图：Boehm的螺旋模型与敏捷方法中的迭代开发很相似 　　 　　敏捷方法将整个软件生命周期分解为若干个小的迭代周期，通过在每个迭代周期结束时交付阶段性成果来获取切实有效的客户反馈。其目的便是希望通过建立及时的反馈机制，以应对随时可能的需求变更，并做出相应的调整，从而增强我们对软件项目的控制能力。所以，就这一点而言，敏捷方法对变化的环境具有更好的适应能力，相比于经典软件工程方法的“计划性”特征，敏捷方法在“适应性”上具有更大的优势。 　　 　　图：作为敏捷方法典型代表的极限编程，迭代开发是其核心之一 　　 　　经典的软件工程方法旨在定义一套完备的过程规范，使软件开发的运作就像是机器设备的运转，人在其中则是可更换的零件，不论是谁参与其中，机器都能运转良好，因此它是面向过程的。这样的做法对于许多软件企业而言，是具有很大吸引力的。这意味着:开发进度的可预见性，流程方法的固化与可复用，人力成本的节省，人员的流动不会对软件开发构成影响。其背后所隐含的观点则是:软件从业者无需是具备非凡智力的高级人才，人是一种可以被任意替代的资源。 　　早在上个世纪70年代，Frederick P. Brooks在他的《人月神话》一书中就曾经指出:向进度落后的项目中增加人手，只会使进度更加落后。在衡量项目的进度时，我们无法将人和时间作为两个可以彼此随意互换的因子。其实这也从一个侧面解答了人是否是可替代资源的问题。而在随后出版的《人件》一书则直截了当的指出了:知识型企业的核心就在于人。 　　在敏捷方法中，人们也非常强调人的作用:没有