高效应用瀑布模型——CODING项目管理解决方案公开课（上）原创

大家好，我是陈欣彤，来自腾讯云coding团队的解决方案架构师，今天我给大家分享的内容是如何使用coding高效管理瀑布式项目。为了让大家知其然并知其所以然，今天的课程会从以下这四个方面分别是瀑布模型的起源、特点、使用场景以及coding基于瀑布模型的产品设计思想和解决方案来阐释。好，第一节我们讲瀑布模型的起源。先来看这样一张图，从1948年初到1960年底的这段时间内，硬件的开发费用在成指数下降，而软件的开发费用却以几乎相同的速率在上升。导致这种现象的原因是复杂的，一方面是因为随着软件系统的规模越来越大，复杂程度也越来越高，另一方面是因为当时的人们缺少系统和规范化的软件开发方法，导致开发过程混乱无序。

其中最突出的问题有以下两点，一是缺少规划和设计环节。随着规模的变大和复杂度的提高，软件变得越来越难以维护，软件开发通常是在失控的情况下进行的。其二是没有考虑软件的可测试性和可维护性。不同阶段的关键文档缺失导致软件交付的失败率居高不下，且运维成本极高。在这种背景下，人们急需一个系统化的、规范的软件开发流程来提高开发的速度和质量，确保软件交付的成功率。基于这样的历史背景，瀑布模型诞生了。讲到瀑布模型，我们就不得不提到一个人，那就是Winston walker Royce，他是一名美国的计算机科学家，同时也是软件开发领域的先驱人物。

他在1970年的时候发表了一篇论文，名为managing the development of large soist，而右边的这张图就是出自他的这篇论文了。每当我们提到瀑布模型的时候，相信很多小伙伴会马上联想到他。现在有很多人都将ROS尊称为the father of waterfall瀑布模型之父，认为他是最早提出瀑布模型的人。有趣的是，在Roy发表的这篇论文中，压根就没有出现waterfall这个词。那么这个词最早是自哪里呢？我们通过查阅大量文献发现，它最早是出自在1976年发表的另外一篇论文，名为software requirements are there really a problem。相隔六年之久，在这篇论文中，他们在引用RO所提出的软件开发模型时，首次使用了water for这一个词，并且配上了右边的这一张图。

虽然这个模型在七六年有了自己的名字，但其实它的起源还可以追溯到更早的20年前。herber在一篇论文中提到，美国麻省理工学院的林肯实验室在开发大型软件时，会遵循一个包含有九个阶段的开发流程，如左边这张图所示。如果大家仔细观察的话，不难发现这九个阶段跟RO文中提到的七个阶段是大同小异的。区别最明显的是，RO绘制的图里前后步骤是呈阶梯状排列的，整个流程看起来就像瀑布一样。如果说RO所发表的论文象征着瀑布模型正式诞生的话，那么其实早在1956年，我们就已经可以看到瀑布模型的雏形了。看完这些资料，我相信很多小伙伴们都会认为，类似这样的软件开发流程图。

就是RO所倡导的，也就是现在所说的瀑布模型。但是事实真的是这样吗？其实不然，这里一直存在着一个巨大的误解，如果完整的把若若文读完的话，我们会发现他认为这个模型是不够完善的，并且针对这个模型所存在的问题提出了五个具体的优化建议。RO的第一个建议是设计先行program design comes first如图所示，他建议在软件需求和分析之间新增一个软件预设计的阶段。这个阶段主要是进行文件系统、数据库、处理器、存储等方面的设计，确保程序不会因为存储和数据流等方面出现问题而导致程序运行失败。这也使得相关的人员在后续的分析阶段中必须将这些因素加以考虑。这样一来，如果原型设计有误或者资源不足，会在更早的阶段被发现。

RO的第二个建议是编写测试文档document the design。这里的测试文档具体包括软件需求文档、软件预设计说明文档、接口说明文档、最终设计说明文档、测试计划说明文档等。高质量的文档可以帮助我们减少沟通成本，提高软件开发的效率，保证软件质量，同时还可以为项目经理在管理项目的过程中提供重要的判断依据。而在软件交付后的运营阶段，良好的文档可以帮助技术人员更好的运营程序，如果没有文档，程序只能由亲自编写他的人来运营了。RO的第三个建议是尝试把工作做两次do it twice。这就是说，在开发程序的时候，先快速完成一个版本，然后在第一个版本的基础上进行改进，最后将第二个版本交付给客户，并且在每一个版本中都包含软件与设计、需求分析、程序设计、编码、测试使用等环节。

这么做的好处在于，第一个版本可以当做是最终产品的一次模拟，通过观察与收集第一个版本在运行过程中可能出现的各种意想不到的问题，我们可以对其进行修复和改进，确保交付给客户的最终产品是高质量的，尽可能没有错误的。Winston的第四个建议是关于测试阶段的，他指出，测试的大部分工作应该由测试专家来负责，如果测试工作只能由软件的设计者来负责的话，那就意味着这个项目的文档工作做的还不够好。如果有好的文档，即使测试专家定位参与软件的设计，他们也能够很好的完成测试，甚至做的比程序的设计者还要好。这些工作包括前期的计划、测试过程、测试中的提前检查、代码测试每一条逻辑路径，质量保证。

其中质量保证具体又分为独立自制的测试分组。配置控制、运维说明、测试标准、过程工具等。除此之外，瑞还强调，在测试的工作中，每当我们解决了一个小问题以后，要马上进行测试，检验修复结果。Roy的第五个建议是让客户参与到项目中来，Involve the customer。因为即使经过了前期的协商，我们和客户在软件需求上达成了初步的共识，开发人员在软件该做什么的问题上仍然存在多种解读的可能，让客户尽早参与开发过程。这里的过程包括系统需求的生成、软件与设计评审、关键软件评审、最终软件验收评审等。

这样做可以澄清一些不确定的问题，减少不必要的返工，从而更快更好的交付我们的软件。若还强调说，客户的这种参与应该是正式、深层次和持续性的。最后的这张图就是ROS将他所提出的五个优化建议进行整合以后得到的一张完整的软件开发流程图。这张图说明了如何将一个充满风险的开发过程转换成能生产出理想产品的流程。RO表示，这里面的每一个改进步骤都是需要额外开销的，不过这些开销都是很有必要的，因为根据他的经验，那些过于简单的开发流程是没办法完成大型软件系统的开发工作的，即使完成了，所耗费的人力和财力也会远远超过增加这五个改进步骤所需要的开销。

通过以上的回顾，我们发现RO清楚的知道广为人知的瀑布模型的优点与不足，为此还提出了具体的优化经营来改进这种开发模式。他认为前后相继的开发模式在小型软件开发中可以起到良好的作用，但随着软件规模的不断扩大，有必要引入一种或者几种改进方法来对瀑布模型做改进。遗憾的是，大家最终却只记住了RO认为存在风险的瀑布模型，并把它当做RO的全部理论主张，不能不说这是一个极大的误解。好，前面我们已经花了教导的篇幅来讲解瀑布模型的起源，接下来我们就来好好分析一下瀑布模型都有哪些特点吧。

瀑布模型一共有三个主要的特点，第一个特点是推迟实现。瀑布模型在编码之前设置了系统分析与系统设计阶段，分析与设计阶段的基本任务是主要考虑目标模型的逻辑模型，不涉及软件的物理实现。第二个特点是阶段具有顺序性和依赖性。瀑布模型的顺序性和依赖性体现在必须等前一阶段的所有工作完成之后，才能进入到下一个阶段。整个流程中最多只有其中一个阶段在工作，其余阶段在等待，并且前一阶段的输出文档就是后一阶段的输入文档。因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。第三个特点是保证质量。瀑布模型要求每个阶段必须完成规定的文档，没有交出合格的文档就没有完成该阶段的任务。完整准确的合格文档不仅仅是软件开发时期各角色之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。此外，每个阶段结束前，我们还要对该阶段所完成的文档进行评审，以便尽早发现问题，改正错误。事实上，越是早期阶段，犯下的错误暴露出来的时间就越晚，排除故障、改正错误所需付出的代价也就越高。这种及时审查机制是保证软件质量、降低软件修复成本的重要措施。

瀑布模型自诞生以来就受到业界的追捧和推崇，并为软件的开发交付团队提供了一整套完整的方法、理论和实践指南，软件开发过程也实现从无序到有序质的飞跃。总体而言，瀑布模型的优势体现在以下几点，一方面是瀑布模型严格规定每个阶段都必须提交文档，增强了过程资产的沉淀，有利于后期的运维工作，另一方面是瀑布模型中测试作为一个单独的阶段，为软件质量提供了流程和规范上的保障，还有就是瀑布模型提供了完整的软件开发生命周期，缩写是SDLC，使得软件管理与协作成为一种规范化和标准化的活动大师。随着软件工程和各种信息技术的不断发展，瀑布模型的不足之处也慢慢显现出来，主要体现在以下几点。一是用户直到项目开发网。

期才能了解产品的真实面貌和质量，软件交付周期长，风险大，其次是需求变更困难，项目早期做出的承诺导致对后期需求的变化难以调整，代价高昂，还有就是软件质量在开发后期才能进行验证和评估，修复缺陷的成本较高。

了解完瀑布模型的优势与不足之后，我们来看看什么场景下适合使用瀑布模型吧。瀑布模型一般适用于以下场景，一种是用户的需求非常清晰且全面，且在开发过程中没有或者很少变化，另一种是对需求变更有着严格控制的项目，例如航空航天、金融和医疗行业的核心系统等，还有就是规模小且低风险项目，比如开发人员对软件的应用领域很熟悉，软件的部署环境非常稳定等。好，接下来就给大家介绍一下coding在项目协同模块所提供的各项能力。在此之前，我们先来看看coding的产品能力全景图，如图所示，Coding是一站式的DELL研发管理平台，主要包含有团队管理、项目协同、cloud studio log、研发规范、持续集成、测试管理、制品管理、持续部署、知识库、文档管理等各大功能模块，涵盖了软件开发生命周期中的各个阶段，可以帮助客户快速落地depo，实现研发项目的全面提升。好，我们现在开始重点讲解coding在项目协同方面的能力吧。

首先，Coding是支持敏捷和瀑布两种不同的工作流的，今天我们主要讲解的是瀑布工作流。这一页PPT罗列的是coding项目协同在瀑布模式下实现的特色功能，包括工程统计、甘特图迭代、概览与统计等。Coding作为一站式平台，涵盖了瀑布模型中从需求分析到应用部署等各个阶段所需要的能力。在需求分析阶段，Coding提供了自定义事项类型和自定义工作流等多种能力，可以为事项状态的流转添加约束条件，从而满足了瀑布模型中不同阶段间具有顺序性和依赖性的特点。

在系统设计阶段，Coding提供了文档管理和添加原型设计图的功能，帮助客户实现过程资产的沉淀，满足了瀑布模型中强调文档的特点。在编码阶段，Coding提供的代码仓库、制品仓库和持续集成等能力满足了客户在代码存储、代码扫描、制品存储、制品扫描和持续集成等各方面的需求。在测试阶段，Coding提供了测试管理功能和自动化UI测试功能，可以大大提高测试效率，同时让测试进度一目了然。在应用部署阶段，Coding提供了持续部署的功能，通过与代码仓库和制品仓库等功能模块的无缝衔接，可以轻松实现多种部署策略，大大提高部署效率。

接下来举一些例子来说明coding基于瀑布模型的产品实现。这一页介绍的是自定义工作流来实现质量管控。团队在飞速发展的过程中，由于业务扩张项目众多，不同项目间的研发流程往往存在较大的差异。以游戏行业的美术开发项目为例，工作流状态一般涵盖文案确认、UI设计、原画设计、模型设计、动画特效设计、确认交付等，而这些状态在一般的软件开发项目中是用不到的。为此，Coding支持自定义工作流，可以满足用户在不同项目中使用不同的工作流的使用场景。除此之外，我们还可以为状态流转添加限制条件。比如说只允许特定人员，例如测试组长将事项的状态从测试中变更为验收通过。又比如，我们可以通过添加附加属性这个规则要求必须填写某个属性例如需求文档的链接，才能将事项的状态从需求分析变更为开发中，从而满足瀑布模型中每个阶段必须完成规定文档的特点。

这一页介绍的是事项间的阻塞关系。前面我们有提到过，瀑布模型的一大特点就是在软件研发的过程中，不同阶段间具有顺序性和依赖性，而顺序性和依赖性体现在必须等前一阶段的所有工作完成之后才能进入到下一个阶段。整个流程中最多只有其中一个阶段在工作，其余阶段在等待。针对瀑布模型的这一特性，Q点允许用户对不同事项之间添加阻塞关系。比如说，我们可以将事项A设置为事项B的前置事项，那么在事项B的详情页面，我们就可以看到其所依赖的前置事项是否都已经完成。如果没有完成的话呢？则应该先完成事项B的所有前置事项，然后再开始事项B的相关工作。通过设置这种阻塞关系，并结合coding提供的甘蔗图，我们就可以快速定位当前阻塞项目进度的事项都有哪些。

这就是coding甘特图的展示效果，通过这张图，我们就可以很直观的看到当前选中事项的前置事项都有哪些，当前是什么状态的，从而快速定位项目的阻塞点。这里也介绍的是工作复杂，用来帮助合理分配人力资源。对于中小型的瀑布项目而言，开发人员和测试人员往往在项目开始后就会全部投入到项目中，而不是分阶段按需投入。这样的后果就是很多加入到项目中的人员并没有被分配到实际的任务，导致人力资源的闲置和浪费。为此，Coding提供了工作复杂功能，帮助解释闲忙情况，从而更合理的分配人力资源。

这一页介绍的是文档管理助理知识沉淀瀑布模型的一大特点是几乎每个阶段都会输出详尽的文档，这些文档能提高软件开发的效率，保证质量，在软件的使用过程中有指导、帮助解惑的作用，在后期维护工作中，文档更是不可或缺的资料。为此，Coding提供了强大的文档管理功能，包括有知识管理、VT文件、网盘和API文档等模块，助力实现知识的沉淀。这一页介绍的是迭代管理，我们可以在一个大瀑布中执行一个小瀑布，并且借助coding以进度跟踪视角来设计的功能，包括迭代详情、事项、状态、趋势图、公式、软件图、活动日志等，从而实现产品的快速迭代，提高交付的速度和质量。