敏捷软件开发与传统软件工程——因果篇

Posted 2020-08-15

因——差异之源

 

　　近来秋将尽，京中阴霾好几日不见好转，更有几天雨水扰人心烦。幸得一日周末，又逢雨过天晴，秋高气爽，捡得几番文笔来细述敏捷软件开发与传统软件工程之异同。

从字面看来，二者无非是“敏捷”与“传统”一词之差。然而这两个词又同属修饰之词，因此就这两个词之差自然就是两种开发方法的差别所在。

敏捷一词，自然是好理解。正如众人所云如游侠身手之敏捷，为称赞游侠反映之迅速，应对变化之机敏。此处用以修饰软件开发，我们亦可套用迅速应变之意，也就是在软件开发过程中能迅速应对需求的改变。至于传统，传统一词有许多注解，佛语曰：色不异空,空不异色。万物并非本来实有，因缘所生。如今要用到此道理来解释传统。这里传统与敏捷结缘，自然用敏捷的反面来解释传统最为恰当。于是，传统就解释为对变化应变迟缓之意。

　　正所谓大道至简，方才所述为敏捷与传统字面词意的区别，而这种区别正是敏捷软件开发与传统软件开发的区别根源所在。以下所述的具体差异，皆因此而生。为求思虑周全，仅用简单罗列对比加以详述其中的异同。

 

果——细述差异

　　仅对敏捷传统二者词义进行词义进行分析，语言略显苍白，不能通达其中的深邃大义。在此对他们定义进行详细说明。

所谓敏捷开发，是以客户需要之变化为根本，用迭代、循序渐进的方法进行软件开发。如何以用户为根本，只能让客户常久持续地参与在软件开发过程之中。然而客户在开发方面毫无认识，又如何让客户参与进来？就只能给客户看成果，提意见了。为了能让客户看成果，软件开发过程中就得保证软件是随时可以运行进来的。敏捷开发有12条原则：

其一，迟早交软件，持续交软件，使客户满意。

其二，欢迎变更，即使在后期。

其三，交付频率短越好。

其四，业务人员和开发人员天天一起工作。

其五，开发人员个人提供支持，并给予信任。

其六，面对面交谈。

其七，把可运行软件作为进度的首要度量标准。

其八，开发速度持续稳定。

其九，关注优秀技能和设计。

其十，简单。

其十一，最好的架构、需求和设计出自于自组织团队。

其十二，团队定期反省。

　　至于传统软件工程，大体基于“瀑布模型”，瀑布式开发是一种传统的计算机软件开发，之所以叫瀑布，自然有李白描述的“飞流直下三千尺”的气势，不过这里指的是一去不回头的势头。它是最典型的预见性软件开发方法，严格遵守计划、分析、设计、编码、测试、维护的步骤。相比于敏捷软件开发，传统式的似乎不把重点放在客户上，而是以软件架构(software architecture)为核心。

实例差异：

　　敏捷开发实例包括极限编程（extreme programming,XP）、自适应软件开发（adaptive software development,ASD）、Crystal、Scrum、特性驱动编程（feature-driven development,FDD）。它是一个标准的，定义良好的，组织持续改进的过程。其中极限编程是敏捷开心使用最广泛的方法。

　　传统软件工程模型包括包括瀑布模型、增量模型、螺旋模型、快速原型模型、喷泉模型等。它们的共同点是项目需要的细节是在开发之前给出的，开发过程客户不会参与，而开发团队会在项目开发完整后一并交给客户。他们的一般流程是分析、设计、开发、测试、实施、维护，整个过程没有客户的参与。或者也可以划分为下面几个阶段：问题定义、可行性研究，需求分析、总体设计、详细设计、编码与单元测试、综合测试、软件维护。各个阶段的工作自顶向下，从抽象到具体顺序进行，每个阶段都必须完成规定的文档，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。

　　这里说到模型，就有必要给模型作一些解释。这里的模型指软件开发过程模型，过程模型描述了软件工程工作中遇到的过程相关的问题，明确了问题环境并给出了针对该问题的解决方案。

方法的应用：

1、主要目标：敏捷开发的目标是以最好的形式适应变更，最大程度地让程序符合客户的需要。尽量缩短可运行软件提交的周期，提高软件提交的频率，来获得更多的来自客户的反馈。

传统开发的目标则是在开发前使与客户进行充分交流，提高软件开发的可预见性、稳定性和可靠性。

2、规模：由于常变和相对较低的可靠性，敏捷开发不太适用于大规模软件的开发。什么叫大规模这里不能给出较为严格的定义。可以想象，当规模达到一定程序时，一开始不做好详细而细致的规划设计是不切实际的。

3、环境：就应用的环境来说，敏捷开发也适用于变更频繁的环境，而传统的软件开发则更睛睐于稳定的，变化小的情况。

开发过程管理：

1、客户关系：这两种开发方法都怎么处理好开发团队跟客户的关系呢？敏捷开发的根本是用户需要，而且在开发过程中，客户会跟开发人员在进行频繁的交流沟通，另外还有可运行的中间成果给客户展示，这些都足以用来取得客户对开发团队的信任和支持。而传统的软件开发模式则不同，它只依赖于合同和规格说明，他们没中间成果给用户展示，开发过程也没有太多的交流，整个开发过程客户必须有耐心等待最终产品完成。而在这过程中，开发团队只能凭靠过程的熟练程度来取得客户的信任。

2、开发计划的控制：敏捷开发一开始没有制订具体的开发计划，计划只能是持续地给用户提交中间产品，并吸取客户意见再持续改进。而传统软件开发则需要制订详细的开发计划，开发人员按计划一个阶段一个阶段地完成开发，并按计划与客户进行有效的沟通和协调。

3、项目的沟通：敏捷开发依赖于频繁的开发人员和客户之间的沟通，虽然沟通很频繁，但是客户对开发工作内部知识可谓是毫不知情的。这样的客户一般都是提一些很模糊的要求，并不能对开发人员用什么方式去开发提供意见，更不能对软件的内部结构进行详细地说明，这样难免会存在风险。而传统的开发则是依赖于文档开发，文档化的知识具有明确性，但是不同的人理解起来就不太一样，这样没有与客户充分交流，同样也存在风险。

技术：

1、软件需求：敏捷软件开发的需求不需要很正式，也不需要很明确，甚至没有正规的文档说明，而只是凭着客户提出的一些模糊的设想去进行开发，在开发过程中再去对需求进行进一步的细化。而传统的开发则更倾向于明确的、详细的、形式化的开发需求，而且开发过程一般不怎么去修改需求。

2、开发：敏捷软件开发对设计的偏好是简单。简单的设计能以更低的成本进行改写和快速地响应需要的变化。传统开发则更侧重于完善细致地设计，这样能增强开发过程的可靠性。

3、测试：敏捷开发在开发之前进行开发测试，并在开发过程中进行不断地测试，而传统开发的测试是对规格说明进行测试。

　　以上从各方面对二者进行了对比，但在总觉缺少点什么。正如放翁一句“纸上得来终觉浅，绝知此事要躬行”，可审察今日这势态，要把两种方法都尝试过是不切实际的了，只好另求它法。于是想到再把二者的典型方法加以介绍，想来也能写到位了。

瀑布模型：

　　瀑布，以一气呵成之态势示人，此处用心修饰软件开发的一种模型，自然是一种顺序型。瀑布型属于传统的软件开发模型，有人称之为经典生命周期，它提出了一个系统的顺序的软件开发方法，从用户需求规格说明开始，通过计划、建模、构建和部属的过程终能得到一个完整的软件并提供持续的技术支持。瀑布模型有最早的软件工程范例之称，然时过境迁，“江山代有才人出”，老的方法终会为现代人质疑其有效性，在新的方法出现后不免被拿来与新方法做对比。由于它属于传统模型，自然有着传统模型的缺点。这些缺点无非是从上文中寻来，在此再做简单例举。比如线性模型不可迭代性，不能确实客户需求的模糊描述，客户必须有耐心等待产品最终才能产生。

极限编程：

　　极限编程是敏捷开发使用最广泛的一个方法。极限编程强调用户和开发者进行紧密的非正式的合作。此外，为了做到简明，极限编程提倡开发者只对即时需求做设计，而不考虑长远需求。这样能让代码设计简单化，方便以后变更甚至重构。在极限编程过程中得到有效的反馈来处于软件本身、客户和软件开发者。

极限编程可分为以下四个活动，而这四个活动是顺循环执行地，重点在于循环。

策划：了解客户的初步需求，为软件各功能设置权值也就是优先级。计算成本，分配工作。

设计：设计追求简单。为软件功能设计实现原则，不鼓励额外功能。

编码：不直接开始写代码，而是先开发一系列用于测试本次开发功能的测试代码。

测试：编码前先写好测试代码是极限编程方法的关键因素。所建立的单元测试应当使用一个可以自动实施的框架。

　　文终处天色已晚。