敏捷软件工程和传统软件工程比较

(注：博文中加粗的正文部分为引用部分)

1、引言

敏捷软件开发从被提出之后就收到了广泛的关注，其从传统开发中剥离开自成一体，逐渐占据软件工程学界的半壁江山，与传统软件开发分庭抗礼。在长期的软件工程发展中逐步形成敏捷型和传统型软件工程相辅相成，并渐渐被软件开发团体认可并运用于实际中。

2、步步为营——传统型软件工程

       传统型软件开发是基于“瀑布模型”的开发方式，以软件架构为核心，采用结构化设计以及分析方法将软件生命划分期限，并且开发进度按照从上而下的顺序相互衔接，如同瀑布一般。瀑布模型是Winston Royce在1970年提出的一种软件开发模型，瀑布式开发是一种传统的计算机软件开发，是最经典的预见性软件开发方法，严格遵守计划、分析、编码、测试、维护的步骤。阶段之间通过文档流通，每个阶段结束时要进行严格的审查，检查功能设计和实现是否符合上阶段流下了的文档的要求，如果不符合就逆流到上个阶段检查并修正，以此往复，直到流到最后阶段产品通过测试后进行发布及运行期间的维护[i]

图1  瀑布模型开发过程

       各个阶段需要文档相互流通，在软件开发前期就需要对整个软件的架构进行设计，优秀的架构可以使软件足以支撑整个功能体系以及便于维护，而这样优秀强大的框架通常需要在十分有经验并且有着独特眼光的架构师在完全理解开发用户的需求之后才可能设计出，通常这个难度是较大的，而这是传统型软件开发的第一步，也是最重要的一步。这样开发的好处是，超前的预见性和每一阶段都要通过严格的审查才能进行下一个阶段，保证了软件的质量。缺点是，软件的框架一旦确定下来就很难改变，甚至会牵一发而动全身，难以适应变换莫测的客户需求。此外，在软件开发过程中需要人员之间交流的并不多，每一个阶段对代码的编写或者测试都由文档规定。由于各个阶段要自上而下相互衔接，各个阶段的沟通要通过大量臃肿、复杂的文档来传递信息。这样的软件开发通常会将每一块的功能做的相对完善（基于明确的文档），而模块之间的衔接以及充分理解文档的时间将显得非常长。

3、灵巧精灵——敏捷型软件工程

         敏捷型软件开发不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人，及突出了人作为软件开发的核心，在软件开发中起到的价值。它采用的是迭代式开发敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

       敏捷型软件开发方法有很多，目前较为被认可和接受的是SCRUM编程和XP编程，及极限编程。在软件开发过程中，将项目切分成几个子项目，以最核心的功能为起点进行软件开发，每当一个阶段的软件开发结束，就交付一个阶段的可用开发成果，并且在保留可更改的能力的情况下对于代码进行优化，总结和经验分析。

图2 Scrum开发模型

    对于Scrum的详细介绍，笔者从博主杨广的博客中学习了很多，为了节省篇幅，笔者在这里给出博客的链接，对于这方面兴趣较大的朋友不妨了解一下，讲解的非常详细。

    博客：http://blog.csdn.net/u012755393/article/details/52790887

4、举个栗子——浅谈两种开发模式

         笔者在国庆期间和几个同学一起开发了一款简单的基于Microsoft平台的UWP（Universal Windows Platform）软件。软件是一个日记本，其核心功能是提供写日记的窗口并且保存日记。在开发初期的讨论会议中确定了开发软件的内容（需求），开发中每个人的分工，然后在国庆期间进行代码编写，测试，最终发布。对于两种开发模式有一定了解之后，这个例子中笔者陷入了一个泥潭：这次的开发，算是传统型软件工程，还是敏捷型软件工程？（尽管在实行过程中有着种种例如根本就没有写文档的一系列问题，此处假设所有的开发过程全部符合软件工程开发的标准，在脑海中自动“.+/”选择补齐对象 (ˉ▽ˉ；)…）

       看上去很像是传统型软件工程开发对吧？从一开始的初期会议确定一系列内容，到分工编写代码，测试，优化，到发布，每一步和上一步都有着很完美的衔接，如果上一步出现了差错，下一步就无法进行下去，如多米诺骨牌式的推动。然而笔者的团队在每次开发阶段截至之后都会对自己当前开发的部分进行测试并且发布一个拥有局部功能的几乎已经完全可用的Demo，并且在开发过程中总结开发经验。这看上去又和敏捷型开发非常相似。

图3 敏捷型开发的五个步骤

事实上，在开发过程中，愚蠢的笔者突发奇想在软件中加入了一些貌似很有意思的东西，虽然这导致软件开发在测试那一个环节卡死了很久，但是软件最终还是按期交付了。我们再把瀑布型的开发过程的图片引用一次：

图4 瀑布模型开发过程

新的想法提出，意味着出现了在一开始定义阶段上的问题，按照传统的软件开发来说，这将是一场灾难并且有可能会无期限的拖延交付时间，而笔者的团队并没有推翻当前的大部分代码，而是直接修改某些核心内容后较为妥帖的合并上了，这很像敏捷型软件工程开发中的“下一个阶段工程”，在和小组成员交流后拟定新的开发计划并且和原来的开发内容合并，并完成合并后的测试，防止愚蠢的笔者再产生一些神奇的想法，似乎可以理解为，为下一个阶段的开发进行分析并且准备下一个阶段的开发。

那么，这个有些不伦不类的开发过程应该算在什么里面呢？

愚蠢的笔者认为，两种都不算……

在开发过程中，如果是传统软件开发过程的话，在计划拟定的环节应该做到尽量详尽，准备完全，而不是遗漏很多看上去理所当然然而并没有被实现的功能。事实上，详尽的拟定计划是可以实现的，如果做到的话，就不会出现之前所说的情况。如果是敏捷型软件开发，应该定期对于工程进行任务汇报，而不是几乎没有太多的交流。敏捷软件开发的一个精髓就是“刚刚够”思想。用逐步实现的思想替代完整架构，每一步的需求和人员及其沟通、开发成本都刚刚好，通过不断地迭代，在迭代过程中响应客户需求的变化，实现最紧致成本，体现“刚刚好”思想。同时对每次迭代的反馈进行讨论和思考，总结经验和吸取教训。按照这个标准，就不应该出现为了添加新的功能而对于核心代码大动干戈。

在这次工程结束后，笔者分析得出，敏捷型开发适用的范围可能较小，团队人员相对固定并且人数有限，对于编程人员的开发经验和能力要求较多。如果开发的程序复杂度规模是日记本的很多倍，那么在工程几乎结束的时候新添加一个功能的难度可想而知。由于笔者团队开发时对于UWP几乎没有任何了解，在开发过程中几乎不能离开资料，遑论体系结构的架构，虽然团队中有开发经验相对丰富的开发者，然而由于缺少交流导致开发过程中并不能对于一些问题提出建设性的看法。总结一下，在笔者认为，敏捷型开发如果要体现其势如破竹的气势，应当满足一下几个条件：

1、开发人员拥有足够的项目经验和编程能力。

2、软件规模适度，开发团队人数较少。（笔者的观点是，敏捷型开发并不如传统开发那样严谨，有可能有较多漏洞，在大型工程中有可能会出现差池）

3、软件开发过程中需要足够的交流，可以使用各种方式，如站立会议，任务看板以及燃尽线等等

4、及时对完成的任务进行测试调试，推出可用的Demo版本，经验总结并为下阶段的软件开发做好准备。

5、结束语

       2016年中国开源年会中，笔者有幸在后台和易软天创的创始人王春生先生对于两种工程开发方式的内容进行一些交谈。在真正的工程中，似乎并没有对于选择敏捷型还是传统型开发看得那么的重。开发方式只是一种方式，并不是敏捷型开发就一定要在极限编程，水晶编程或者Scrum编程中选择，其更多的是一种工程思想，在学习中不应该将自己过分的限制在教条中，把何为传统何为敏捷当成范本在合适的工程中生搬硬套。最重要的还是学会分析软件需求，按照实际情况选择不同的开发方式，或许有些大型项目敏捷型开发会更加有用，而某些小的工程也需要传统方式的严谨。

敏捷软件工程和传统软件工程的比较