敏捷开发管理模式是否适合软件外包企业

庄贇祺

在软件工程领域，有过很多软件开发模型，如瀑布模型、快速原型模型、增量模型、螺旋模型、演化模型、喷泉模型、RAD模型、敏捷软件开发模型、XP极端模型。这么多的模型各有各的应用场景、各有各的适用范围。

如今，敏捷开发被越来越多的开发企业和团队所接受。使用恰当，不仅可以显著提高开发效率，也可以缩短产品的开发周期。问题是，“敏捷”方法是否能适用到软件外包行业，这个争论由来已久，各有说辞。作为软件外包商，我们发现，在一个长期的合作过程中，如果使用敏捷开发模式，不仅可行，而且的确能够形成一个双赢的局面。

一、敏捷开发主要理念和框架

敏捷开发主要以迭代式增量交付為基础，小批量地交付可工作的软件，其中一切都是从产品待办事项列表开始的，我们都知道，大批量的工作同时展开是浪费之源，所以从源头就需要将大块头的任务进行拆解，借助persona、场景分析、MVP 梳理等过程进行用户故事的拆分，并进行排序和评估，从而安排每一个迭代的工作。迭代增量式交付一开始看上去总会很美，但很快就会遇到问题，其一是增量式的交付会带来无止境的回归测试，其二是不可避免的代码腐化，其三是尽管需求可以拆分得很小，但由于固定的人只能做固定的事，在调配资源的时候就会捉襟见肘，这也是很多大公司面临的问题。

对于这三个问题，敏捷开发都给出了自己的解决方案，它倡导将质量内嵌在开发过程中，质量保障工作是贯穿始终的，技术水平的提升也让自动化测试、持续集成成为可能，同时敏捷开发认为代码总是动态修改的，所以我们应当掌握的技能就是重构和测试驱动开发，好的架构是生长出来的，而非几个架构师用PPT 画出来的，最后提倡学习型组织，技能扩展，一专多能的人才是现代软件开发中最需要的，所以以特性团队的方式取代老的组件团队，一切以交付优先，而这也就是PMBOK中提到过的强矩阵和弱矩阵之间的关系。

二、敏捷开发的几种主流方法

（一）SCRUM

SCRUM是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。

该方法由Ken Schwaber和 Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进。

（二）DSDM

DSDM（动态系统开发方法）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发像。实践证明DSDM是成功的敏捷开发方法之一。DSDM不但遵循了敏捷方法的原理，而且也适合那些成熟的传统开发方法有坚实基础的软件组织。

（三）XP

XP（极限编程）的思想源自 Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做 出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。

三、敏捷开发的优势

（一）沟通的威力

肖伯纳有一句名言“England and America are two countries divided by a common language。”意思是英国和美国是被一个相同的语言所分隔的两个国家。这里不是指的地理上的分隔，而是文化沟通上的差异，即便他们都说一种语言。不同的时区，不同的文化，不同的工作方法和原则，导致沟通成为了我们进行外包的一个瓶颈。敏捷开发既强调了沟通，又为顺畅的沟通提供了方法和指导。其中持续的交付实际是在用实实在在的形式进行了项目的沟通，从而降低了最后的交付风险。作为传统开发模式，比如一个瀑布式的开发，六个月后，客户才能第一眼看到自己想要的产品，这里面能产生错愕的概率有多大，大家可以想象一下。

（二）勇于面对改变

需求变更在整个软件开发的生命周期中是一个永恒的话题。也是客户与服务提供方最纠缠不清之所在。改变的导火索可以来自方方面面，既有可能是一觉醒来后的灵光一现，也有可能是来自客户外部商业环境的改变。如果处理得当，这种变化可能协助双方得到一个更优秀的软件，也能让客户对你的快速应变产生好感。另外，我们总是陷在一个自己预设的陷阱里，客户的要求改变永远是对功能的增加。其实，一个过程中的再设计，有可能会降低开发的成本。

（三）迭代是趋于完美的过程

罗马不是一天建成的。不要尝试对完美的一步到位，除非你的用户愿意牺牲宝贵的进入市场的时机。只用尽最大可能不断地从客户那里得到进程中的反馈，进而对开发加以修正，才不会出现最终和用户意愿的大偏差。例如在双方可以接受的情况下，定义若干个短促有效的迭代过程，第一时间发现问题，放到下一个迭代中去解决。

（四）质量保证

敏捷开发这种快速交付，让用户能够尽快试用你的功能，尽快发现问题，就整个开发周期而言，整体质量一定会得到提升。在传统开发模式中，我们都会或多或少遇到这样的情况，因为开发时间的拖延，测试时间永远是第一个被压缩的阶段。结果可想而知。更多的迭代引入了更多的测试周期和时间。

四、结束语

任何一种理论框架我们都应当辩证地去看，既然是管理项目，我们应当因地制宜，每一个项目因为它规模大小、产品面对的市场都有所不同，例如移动APP和大型通信类产品，300人的项目和10人的项目，在项目立项之时我们就应当确定项目管理的策略，究竟应当采取什么样的管理方式、工具、过程，而这个过程恰恰是在PMBOK所处的理论层面上进行，进一步我们可以采用敏捷开发所提供的工具库来实现我们的管理框架和策略。

参考文献：

[1] 陶思俊. 从IT 项目管理看待PMBOK 和敏捷开发[J]. 邢台学院学报，2015

[2] Taskcity. 再谈敏捷开发的好处及敏捷外包的前景[J]. 51CTO，2009