从MiniGui十年开发经验看瀑布（传统开发模型）和SCRUM（敏捷开发模型）

看了一篇关于MiniGui开发公司的十年回顾，里面有一部分关于 瀑布 和 SCRUM 的区别，觉得有些道理，所以在此做个记录，同时也分享给各位看官！

在飞漫软件发展各阶段，我们曾采用过多种软件开发管理模型。

以 MiniGUI 为例。最初，基本上是作坊式的小团队，没有独立的质量保证团队。MiniGUI 1.0 到 2.0 的各个版本，基本上出自本人以及当时公司的另外一个主要创始人Snig。那时，基本上没有什么管理，靠的是兴趣和一腔热情编码。

在飞漫软件开始开发一些 MiniGUI 的外围软件时，比如简易浏览器（mSpider）、PMP 方案（mGallery），很自然地想到引入质量保证团队来协助开发团队保证软件的质量。

时间推移到 2008 年，在我们开发 MiniGUI 3.0、mDolphin 等产品时，飞漫软件内部形成了一套严密的、基于瀑布模型的软件开发管理模型和体系，制定了一系列的软件开发管理规范和工作规范。最多时，围绕 MiniGUI 3.0 开发的人员总人数高达 20 人，其中包括产品管理团队（含产品经理、UI设计师等）、开发团队以及质量保证团队。

直到 2011 年 4 月，笔者从未考虑过我们投入 20 人的团队开发 MiniGUI 3.0，到底是不是值得？暂且不说是否脱离了市场，但在长达一年多的开发过程中，层出不穷的缺陷和不停的小版本演进，到底给飞漫软件以及用户带来了什么？

直到 2011 年上半年，飞漫软件和一家老美公司合作开发一个 ACL 项目时，笔者才发现，我们多年来自然而然坚持的一些软件开发管理方法，其实并不是最佳的方法。该项目试图为不同的操作系统引入一个统一的 Android 兼容层，使得标准的 Linux、Windows 或者 RTOS（如 VxWorks）上，能够运行 Android 应用程序，开发过程采用了 SCRUM 敏捷开发模型。本人花了两天的时间阅读了两本有关 SCRUM 开发模型的书，结果得到一个惊人的结论： 传统的软件工程思想，其实是一个大大的骗局！

传统的软件工程思想，以“瀑布法”为典型，按照需求分析、设计（又细分为概要设计、详细设计、单元测试设计、测试用例设计）、编码、测试的过程进行管理，不停迭代，直到缺陷数量降低到零，或者缺陷数量从最初的几百个收敛到几个，才认为是形成了可正式发布的版本。但这个过程极其漫长，MiniGUI 3.0 从第一个可发布版本 3.0.2 发展到基本稳定的 3.0.8，跨度居然长达一年半时间。

为了有效实行瀑布法模型，我们制定了详细的过程管理规范，从需求分析（草案）的编写、概要设计、详细设计、单元测试设计到最后的测试用例开发，每一步都要求形成对应的文档，经过评审后进入下一个单元。比如，软件架构师负责分析需求并进行概要设计，高级工程师来编写详细设计文档，经软件架构师审定后进入下一个环节，等等。看起来，一切都那么完美，只要每个人都按照要求和流程来做事，没有达不到的目标。但现在想来，这其中存在如下一些深层次的问题：

   * 文档流于形式。一方面是因为开发人员本身对文档工作存有天然的抵触情绪，另一方面，开发人员并没有受到过如何撰写开发文档的培训。自然而言，文档描述不清、不及时更新等问题就出现了，最后，文档基本上就会流于形式。通常的结果是，需求文档或者概要设计文档写得很好，但详细设计文档、单元测试文档等等，越往后越差。

   * 没有人仔细阅读文档。大部分开发者其实不会仔细阅读文档，他会根据自己对需求的理解进行编码，即使详细设计文档就是他自己编写的，他仍然会给你敲出一份偏离详细设计的代码。

   * 瀑布开发模型，忽视了软件质量的第一保证人是开发者本人这一要求，使得开发人员非常依赖于测试人员，测试人员又抱怨开发者编写的软件充满了缺陷。最后，使得整个开发过程充斥着责任不清和相互的埋怨，大大降低了开发效率，质量也很难得到保证。

然而，如果我们仔细回想 MiniGUI 早期版本的情况，我们会发现，那时，没有专职的质量保证团队或者测试人员，就两三个开发人员，软件的质量仍然相当好。再比如，Linux 内核的开发过程显然也没有采纳瀑布模型，但为什么仍然取得了那么伟大的成果？

如果你仔细想想这其中的奥秘，你就会发现，传统的软件工程思想，是模仿传统工程管理方法，比如建筑工程的管理方法设计出来的。瀑布模型，有其可适用之处，但并不是万能药。在任何一个软件开发中，期望通过传统软件工程方法来进行管理并取得良好效果，基本上属于一厢情愿。

为什么笔者认为传统软件工程思想是一个骗局呢？其一，宣传传统的软件工程方法，为那些靠 CMM 等软件管理标准或者规范吃饭的人给了一个可以赚钱的机会；其二，利用传统的软件工程方法，为那些贩卖项目管理软件的公司一个可以赚大钱的机会；其三，传统的软件工程方法，创造了更多的就业岗位。

自从笔者接触了 SCRUM 开发模型后，我发现它和传统软件工程方法最大的不一样，就是：前者围绕软件本身进行管理，后者围绕流程进行管理。SCRUM 开发模型强调 3C，即 Card（卡片）、Confirmation（确认或承诺）和 Communication（沟通或交流）。该方法去除了一切形式化的东西，比如复杂的文档和流程，让开发过程关注到最终可以交付的软件及其功能的演进上。而且，采纳 SCRUM 开发模型时，它的管理手段非常简单，任何有基本管理素养的人，只要遵照其基本原则和方法，都能做好相应的管理工作。

然而，SCRUM 开发模型的执行过程非常容易走样。很多人仍然喜欢使用电子化的方式来管理项目，比如使用 ScrumWorks 这样的软件，但这其实违背了 3C 原则中的 Card 和 Communication 这两项；很多人非要按照一周、两周或者一个月来划定一个冲刺的目标而不是按照冲刺工作集来确定发布时间；甚至一些管理人员，连燃尽图都懒得画。

（2012-08-19，文章来源： 飞漫软件十年回顾）