从瀑布式到敏捷式：持续化集成的转型之旅 (瀑布从远到近)

随着软件开发行业不断发展，敏捷式开发方法逐渐成为主流，取代了传统的瀑布式开发模型。敏捷式方法强调迭代、增量开发和持续集成，这有助于提高软件开发效率和代码质量。

本文将探讨从瀑布式开发模型向敏捷式开发模型转型的过程，重点介绍持续化集成的作用。

瀑布式开发模型

瀑布式开发模型是一种线性的软件开发方法，它将项目分解为一系列阶段，包括：

1. 需求分析
2. 设计
3. 实现
4. 测试
5. 部署

瀑布式模型的问题在于，它是一种严格的过程，缺乏灵活性，无法快速适应变化的需求。由于测试阶段通常在开发周期后期进行，因此发现和修复缺陷的成本很高。

敏捷式开发模型

敏捷式开发模型是一种迭代、增量的软件开发方法，它强调：

1. 持续交付
2. 客户参与
3. 团队合作
4. 适应性

敏捷式模型将项目分解为较小的迭代周期，称为冲刺。在每个冲刺中，团队都会交付一个可工作的软件增量。这有助于获得早期反馈，并允许团队快速调整其工作。

持续化集成

持续化集成（简称 CI）是敏捷式开发过程中的一项关键实践。CI是指在每次代码更改后自动构建、测试和集成代码的自动化过程。

CI 的主要好处包括：

1. 提高代码质量： CI 确保每个代码更改都经过构建和测试，这有助于防止缺陷进入生产环境。

2. 缩短反馈循环： CI 提供了快速反馈，让开发人员能够快速识别和修复缺陷。
3. 提高团队协作： CI 鼓励团队成员频繁地提交代码并在单个分支上工作，这有助于减少冲突和提高协作。

从瀑布式到敏捷式的转型

从瀑布式开发模型向敏捷式开发模型的转型需要一个渐进的过程。以下是过渡的主要步骤：

1. 建立敏捷团队： 建立一个跨职能的敏捷团队，其中包括开发人员、测试人员和业务代表。
2. 制定敏捷流程： 制定一个适合团队需求的敏捷流程，包括冲刺计划、日常站会和代码审查。
3. 实施持续化集成： 使用 CI 工具自动执行构建、测试和集成代码的过程。
4. 提升自动化水平： 使用自动化工具来自动化测试、部署和其他任务，以提高效率和减少人工错误。

5. 持续改进： 定期回顾和改进敏捷流程，以最大化其好处。

结论

从瀑布式开发模型向敏捷式开发模型的转型是一项变革性的旅程，可以显著提高软件开发效率和代码质量。通过实施持续化集成，团队可以获得早期反馈，提高代码质量，并缩短反馈循环。

虽然转型可能具有挑战性，但好处是显着的。通过拥抱敏捷式开发和拥抱持续化集成，团队可以释放其全部潜力，并构建出色的软件产品。

---

敏捷团队の定义

敏捷的团队是自我反省、持续调整的团队一、敏捷项目管理：（1）Iteration软件开发模型经历了从瀑布到螺旋再到敏捷的过程，迭代不是敏捷独有的创造，无论在RUP还是在MSF中迭代都是其核心特性之一。 而在Tencent特别强调的是并行迭代，即多个版本并行，最大程度发挥资源的效率。 Release（发布）可理解成当实现的产品Feature累积到一定用户价值时的正式发布，它是比Iteration更大的概念；Iteration（迭代）是在固定时间内开发Feature的过程，Release一般包括多次Iteration。 （2）TimeBoxTimeBox（时间箱）反映了敏捷开发的节奏，即在固定时间内实现不固定特性的周期，抛开需求定义阶段，从设计-实现-测试到部署，在Tencent一般一至两周时间居多。 （3）Planning Game对敏捷的一种常见误解是不要计划，其实在敏捷的体系中不仅强调计划，甚至区分Release计划、Iteration计划和Task计划等多种不同粒度、不同时长的计划。 Planning Game突出的是让用户代表参与，由用户代表评估UserStory/Feature的优先级，开发人员评估任务的开发时间，由用户代表+项目经理+核心成员三方共同排序、组合，确定本次迭代计划需要实现的Feature List。 在Tencent用户代表就是产品经理。 （4）IterationPlanningMeetingIterationPlanningMeeting就是Planning Game实现的管理形式，通过会议沟通达成。 （5）Stand-up Meeting团队成员围成一圈，逐个说明3个问题：昨天做了什么，今天计划做什么，有没有困难并计划如何解决。 对Team而言这是检查进度、快速调整非常有效的形式，在Tencent这已经成为大家每天早上的固定习惯。 （6）ShowCase提交测试前由开发人员演示实现的功能，产品经理到场Review是否符合当初的设想，避免接近发布时才反馈。 （7）Retrospect每个迭代结束后，项目经理组织或轮流组织所有Team成员共同回顾本次迭代的得与失，整理Well/LessWell，因为敏捷的团队是自我反省、持续调整的团队。 二、敏捷软件开发：（1）Story Card/Story Wall/Feature ListStoryCard是XP中推荐的需求定义方法，要求符合Invest和Moscow原则；StoryWall则用于跟踪StoryCard的变化状态，而FeatureList是Tencent一直沿用的需求表达形式，在Tencent的TAPD工具中已经实现了类似ThoughtWorks 的Mingle的StoryCard管理功能，对于需求跟踪而言这是不错的方法，一目了然。 （2）Refactoring相信我们都听过这句话：好的代码不是设计出来的，而是重构出来的。 （3）TDD“测试驱动开发”在Tencent执行地并不太好，Tencent的产品以Web形式居多、业务逻辑相对简单，C++下的单元测试有些力不从心。 相反自动化测试在Tencent比较盛行，因为有测试部门专门的自动化测试Team在推动，而且链接的是正式生产环境，可以即时反映产品当前的状态。 （4）Pair programming理论上结对编程可以提高代码的质量，而且并不会降低开发效率，但Tencent的业务繁忙，资源上不允许两人结对。 （5）CI持续集成可以降低发布前集成阶段的难度与成本，Tencent的自动化构建系统推行的比较早，覆盖了大多数产品，而且正在朝自动化构建-自动化测试-自动化发布三者协同的目标迈进。 （6）灰度发布灰度发布是Tencent的又一创新，它将产品试用扩大到海量用户一端，在小范围及时吸取用户反馈，分析用户行为和喜好，持续修正自己产品的功能体验。 当然开发方法和流程确定了还远远不够，更难的是如何将它推动落地。 首先Tencent组织开发了承载敏捷思想的TAPD项目管理工具，它类似 ThoughtWorks的Mingle；然后推出了敏捷能力模型，类似CMM成熟度模型一样对Team评级加以引导；同时还推出了敏捷指数排行榜形成竞争，营造你追我赶的声势氛围。 文章写到这里行将结束，最后我们分析Tencent为什么选择Google和ThoughtWorks，其实是由互联网行业本身的特点决定的，互联网的生存法则就是大鱼吃小鱼、快鱼吃慢鱼，谁转身的快、谁拥抱变化、谁更关注用户，谁才可以笑到最后。 阿里巴巴董事局主席马云说过：今天很残酷，明天更残酷，后天很美好，但绝大多数人都死在明天晚上，却见不到后天的太阳。

全面解析瀑布式开发和敏捷式开发

在软件开发领域，瀑布式开发和敏捷式开发是两种常见的开发模式。 毕业后的职业选择常常让人感到困惑，对于非专业背景的人来说尤其如此。 以我的经历为例，从编导转入互联网产品行业，面对的是用户画像、技术术语等新挑战。 初入软件行业，瀑布式开发和敏捷开发的概念频繁出现。 瀑布式开发以其严格的需求-设计-开发-测试流程，适合需求明确的B端项目，但其缺点是过于受制，一旦产品不符合市场需求，可能导致延期发布和高昂的成本。 微软的Office和Windows更新周期漫长，是其瀑布式开发模式的体现。 相反，敏捷开发更注重用户需求的迭代和快速反馈，适用于需求不明确或竞争激烈的项目。 微软的Visual Studio 2010的更新速度加快，反映出敏捷开发的优势。 国内的禅道项目管理软件，通过Scrum的管理思想，实现了快速迭代开发，是国内软件行业的一个成功案例。 瀑布与敏捷并非绝对对立，而是灵活运用的。 项目管理的关键不在于遵循哪种模式，而是如何在实践中灵活应对，预防和解决问题。 适应新事物需要时间和勇气，但每日的收获和对新事物的好奇心，使我们在不断学习中成长。

制造业产品开发中应用敏捷Scrum的思考 （下篇）

上篇作者作为一名机械制造业的从业者，简单介绍了敏捷Scrum，并分享了一些对Scrum理念的理解。 下篇以制造业产品开发中应用敏捷Scrum的思考进行了一系列的分享。 点击链接阅读：敏捷Scrum理念的背后—写给机械制造行业同仁（上篇） 作者 : Sven Fang 房世庆 Scrum硬件及制造业专家 德国杜伊斯堡艾森大学机电工程专业博士 如同IT行业，制造业也面临着越来越严峻的挑战，市场要求企业能够做到更快的产品更新，更低的成本和更高的质量。 在IT行业日益得到推广的敏捷Scrum框架给制造业的产品开发带来许多启发。 不少企业已经开始尝试改变传统的瀑布式产品开发模式，应用敏捷Scrum框架以快速适应市场变化，控制风险和提高客户满意度。 本文在考虑国内制造业特点和目前状况基础上，就如何应用Scrum框架和理念表达作者的一点拙见。 这里假设读者已经拥有敏捷理念和Scrum框架的基本知识。 1制造业产品开发的运作方式 图1普遍采用的产品开发项目流程 这里所说的制造业是广义的制造业，区别于软件业，以“物理”对象为产品，如机械，仪器，仪表，工具，汽车业，家电等等。 在软件业，习惯把所有非程序类产品称作“硬件”。 为避免和PCB板之类的硬件电子产品混淆，我们这里没有用“硬件”一词。 制造业悠久的发展历史，积淀了百年的经验，很多约定俗成的理念和方法源远流长。 “现代”产品开发的运作方式受泰勒（Frederick Taylor）和法约尔（HenriFayol）的思想的影响，采用“瀑布”(或称 “串行”)式的方式，高度重视计划、分工、职权和控制。 其实产品开发的理念及流程和变革前的软件行业没有本质区别。 以汽车零部件行业为例，产品开发是一个计划性过程控制，一般产品开发都以项目形式管理，项目经理对项目的成本、进度以及交付负责。 在产品开发前，客户和企业就产品需求以合同的形式固定下来，从明确的需求开始，制定开发计划，分工开发组件，集成后测试，冻结设计，模具释放，工艺方案设计及实施，样件，最后批量生产。 （如图1所示）。 对于产品换代缓慢，大规模生产的时代，这是最合适的方式。 今天的世界已经不是昨天的世界了，为追求更高利润，单纯地扩大规模以降低成本已经不够，市场竞争压力越来越向产品开发部门转移。 传统的基于计划的开发理念和运行方式对于那些必须开发复杂产品（复杂产品未必结构复杂）以提高市场溢价权的企业来说，很可能导致企业的衰退。 面对更多不确定性的当下世界，大家都意识到下列问题必须解决： -局部优化是不够的，必须以系统思维开发产品 -仅有销售部门面向客户是不够的，必须面向客户开发产品 -再完善的开发计划都赶不上变化，必须拥抱变化 -再专业的项目经理都是不够的，必须要团队协作 -等等敏捷理念下的Scrum框架，采用跨职能团队、迭代增量、持续可交付产品等方法为我们提供了这种变革的一种可能。 2敏捷Scrum在制造业的实践 这里要提到的是，其实机械制造行业很早就接触并应用了敏捷理念。 作者认为，大家熟悉的“精益生产”理念其实就是敏捷理念的源头，甚至敏捷理念下Scrum的构思也起源于制造业 [Kenneth S. Rubin, 2012]。 从“精益生产”理念扩展而来的“产品生命周期管理”（PLM）、“并行工程”(Concurrent Engineering) 已经被一些企业自觉或不自觉地运用到产品开发中[熊光楞主编，2011]。 所谓“并行工程”旨在整个开发工作都着眼于整个过程和产品目标，避免传统的“串行”开发模式带来的弊端，其中不少地方如“跨职能团队”，“产品导向”都能看到和敏捷Scrum类似的宗旨和方法。 敏捷理念下的Scrum框架简单，有其独到性，这也是为什么在软件界得到迅速的认可和普及。 尽管传统制造行业的产品开发和软件行业有所不同，但Scrum在软件行业应用的成功使得硬件及制造业的管理者们开始尝试在本行业的应用。 走在前面的是那些包含嵌入式软件的供应商以及一些仪器设备供应商们。 然后慢慢延伸到纯机械制造行业。 正如Rubin提到的：虽然 Scrum 最常用于开发软件产品, 但 Scrum 的核心价值和原则可以而且正在被用于开发不同类型的产品或组织不同类型的工作流程。 例如, 我曾与成功使用 Scrum 的组织合作, 以组织和管理与硬件开发、营销计划和销售计划相关的工作。 [Kneneth S. Rubin, 2012]这里我们列举两个业界的例子，可以说是基于敏捷Scrum框架进行的产品开发。 2.1波音777的研发 波音公司从1990年概念设计开始到1995年5月在联合航空投入商业运营，在6年里成功完成了一个50亿美金的新产品波音777开发项目，参与员工达1万多人。 项目负责人 Alan Mulally创新地运用的“一起工作”模式其实体现了敏捷理念。 Mulally组织起了约250个多功能团队DBT（DesignBuild Team），每个DBT团队负责一个功能模块。 每个DBT都由综合多样的人员组成，可以完成从概念到制造和维护。 团队中有设计，制造，模具人员，财务，材料，维护，分包合同代表，客户代表。 所有DBT每周进度例会保证团队之间的沟通协调，为进一步做到透明开放的沟通，他将波音777的所有个员工每个季度都汇集到西雅图，开为期两天的all-team meeting！这样的会议在30个月里开 了9次（见图2）。 匪夷所思！ 图2. 波音777及西雅图大会。 Source:对于那些小的日常的变化，DBT多功能团队会来处理新涌现的信息，并在制造和设计工程师之间形成快速的反馈循环。 需求变更以往需要消耗几周，但是在DBT团队一天就可以搞定了。 当你可以快速合作，应对变化就会变得更容易。 777是几乎完全使用三维CAD软件代替二维图纸设计的第一架飞机。 在建造第一个原型之前，3D CAD模型就可以组合在一起进行实时验证。 这就加快了反馈闭环的形成，增量的质量也有一定的提升，从而能够更早更好地得到反馈。 波音通过许多举措让客户参与到开发中来，并强调和客户的合作高于一切。 由于客户的参与，客户快速反馈，团队可以及时响应变化而非无条件遵循计划。 在这里Scrum框架的跨职能团队、迭代增量等均有体现。 较详细资料请参见“Agile at Boeing in 1990s – the 777 Program” 链接：以及唐怡佳的“硬件敏捷先驱——波音777案例分析”；链接：2.2Wikispeed 图3. Scrum in Wikispeed, Source:提到敏捷Scrum在制造业的应用，大家都愿意拿Wikispeed举例。 Wikispeed 是一个汽车制造组织，它使用面向世界开源（OpenSource）的方式制造有上路许可证的节能汽车。 它的员工由分布在全世界20多个国家的近200个自愿者组成，用户可以在网上订购从世界不同地方生产的9个模块组件组装成定制的汽车，目前，可选汽油机或电动机为动力。 Wikispeed曾经运用Scrum框架在3个月内开发并制作出一辆原型车。 Wikispeed 的开发特点可以总结以下三点[Shantam Shukla,2013]：-开源设计 如我们以前熟知的Linux系统的开发，Wikispeed的团队开放资源，吸引全世界的造车爱好者参加到开放中，自愿者们大多利用业余时间参与团队并完成部分工作。 -模块化及测试驱动开发 Wikispeed团队将整个汽车分成8个模块，每个模块由来自世界各地的一个或多个团队自愿者负责开发，成员一般是该领域的技术专家或爱好者。 为了实现开发和组装的灵活性，为每个模块定义了“通用”接口，以实现即插即用的理想。 虽然模块化设计导致模块内的冗余，可能会导致局部成本的增加，但考虑到客户的多样性和灵活性的要求，以及Wikispeed 开发组织的特点，从系统角度考虑，这是个明智的选择。 对于每个模块的开发, 团队最开始先构建了重要的测试要求。 例如， 一个从事底盘设计的团队可以以任何方式开发它, 直到它满足最初的测试要求。 -Scrum框架组织开发 发起人JoeJustice是软件工程师出身，用业余时间开发并制作一辆汽车对于他和他的团队来说是充满不确定性和挑战的项目。 由于是开源的形式，为了管理和协调来自不同地区、不断壮大的志愿者团队，他和Wikispeed的其他成员使用Scrum的原则协调分布式虚拟环境中的开发。 开发团队承担Sprint的任务, 并尝试在7天内实现预期结果。 Sprint的任务由团队中的产品负责人（Product Owner）定义，并负责定义正在开发的模块测试的要求和参数。 不同的Sprint可能有不同的产品负责人自愿担任，他往往是该Sprint任务领域最专业的人士。 由于是自愿、开源的形式，团队中没有主管, 也没有说由PO来确定团队任务的优先级。 图 source：[Shantam Shukla,2013]3制造业应用敏捷Scrum进行产品开发的一些问题 “如何在机械制造行业成功地应用Scrum？”，这个话题太大，涉及到的方面太多，一本书的篇幅也很难阐述清楚,我们或许可以把问题分成两类：一方面其实是制造业的人文问题，另一方面是技术问题。 所谓人文问题，是制造业根深蒂固的传统理念，和许多固化的思考及行为方式。 所谓技术问题是指：制造行业的产品对象为“物理”实体，在开发过程中会遇到很多和软件业不同的问题。 但必须承认， 有时候很难区分是人文还是技术问题，有时候表面上看似是技术问题，其实是人文问题。 在制造行业应用敏捷Scrum，首先需要深入理解企业，从产品、当前的组织管理架构、组织文化、人员状况等多维度，考虑是否合适采用Scrum框架以及实施的节奏。 不是每个组织都适合采用敏捷Scrum，也不是每个企业的Scrum都是一模一样的。 3.1应用敏捷Scrum的人文问题和思考 组织文化 Scrum的成功需要文化机制来保证。 “试图改变一个组织的文化是愚蠢的，它总是以失败告终。 人的行为（文化）是制度的产物； 当制度改变时人们的行为才会随之而变。 ”[Craig larman and Bas Vodde，2016] 而改变机制需要改变一个根本的观念：对“人”的观念。 敏捷理念是建立在“如何利用人的潜力”这个基础上的：如果给与机会，人类广泛具有想象力，创造力；人们会为自己所认可并承诺的目标做出努力，承担责任。 而传统的管理模式是基于假设：人们逃避责任，没有主见，本性懒惰。 麦格雷戈在他的《企业的人性面》中把建立在这两种假设上的管理理论和实践称为Y-X理论。 对“人”的根深蒂固观念受文化和教育的影响很难改变，直到今天，我们国内学校还在按传统的假设（X假设）培养我们的下一代。 可想而知，敏捷理念的实施和落地在国内将遇到多少困难。 传统的对“人”的观念，已经渗入我们传统行业每个管理者和被管理者的骨髓。 在采用Scrum实践中，管理者往往有强烈的变革意识，希望推动Scrum，但他们习惯的不经意的“控制”行为往往阻碍Scrum的成功，个人绩效是个“控制”的例子。 从组织管理角度，重构机制，降低管理者的“控制欲”，使管理者成为引导，教练型角色，给与个体贡献潜能的空间，作者认为是Scrum成功的条件。 敏捷Scrum的采用提供了变革的工具，但如果没有机制作为保障，只能带来混乱 （本人也是X假设下培养出来的）。 想象一下，取消个人绩效取而代之的是团队的绩效，由团队自己决定收益分配，仅仅就是这一点机制的改变，在国内制造业的人文环境下就很难实现。 由于有各种人文阻力要比软件业更大，Scrum的采用步骤和规模值得注意。 虽然我们有波音777的大规模研发中使用敏捷理念成功的案例，但个人还是建议循序渐进地在机械制造行业采用Scrum。 通过小规模地采用Scrum，适应新的思维和行为规范， 最重要的是试验新的文化机制。 Scrum只提供了一个框架，在许多方面它没有提供明确答案，而其他没有说明的，如文化机制却决定了其实效性。 实施Scrum的具体建议见在章节3.2。 成员状况 对比软件业，我们不能不承认，制造业研发从业人员的平均年龄都偏高，由于各种原因，对待新事物的态度偏保守。 在硬件及制造行业，专业化很强。 开发人员往往只具有某项专业技能，需要多年的工作经验成为某专业的专家，一专多能较难实现。 在开发中，对这样的专家依赖严重。 这样的状况有时是产品本身特点造成的，有时是传统组织架构长期累积的结果。 在实践Scrum前，一个重要准备是需要企业内部各个层面及个体对敏捷理念，Scrum框架以及其背后宗旨的深刻理解。 在此基础上才可能灵活运用敏捷Scrum以达到目的。 另一方面，在组织中自上而下的推动，自下而上的实施成功率要高些，因为Scrum挑战很多传统的思想和行为，会涉及到个人或组织阶层的固有利益（非公司利益）。 3.2应用Scrum的技术问题和具体建议 讨论了应用Scrum的人文方面的问题后，下面讨论普遍存在的所谓技术问题。 产品开发的复杂度 Rubin在他的Essential Scrum 一书里把要解决的问题分成了5种，并非所有问题都适合Scrum框架。 Scrum框架一般较适合于解决较复杂的、不确定性强的开发，尤其是有很强的探索性开发。 一个以委外加工为主，设计图纸又由客户提供的公司，Scrum很难带来大的改变。 不少领域的工作使用Kanban可视化管理就能收到很好的效果。 产品的测试环节需要较大的资金投入，并且准备时间及制作周期长 由于产品对象是“物理”实体，相比软件业，制造行业产品开发有如其特殊性。 很多产品的样件往往需要模具，尽管可以使用 “软模具”，但依然成本很高。 漫长的制作时间往往成了项目开发周期的瓶颈。 除此之外，模具及样件往往由外部供应商提供，有时还需要考虑采购部门的选择定点时间。 样件制作是项目经理最头疼的一件事。 以汽车零部件企业为例，为了小规模采用Scrum来提高企业应对市场灵活能力，推荐在企业的预研发（pre-development）环节先实践Scrum框架。 一般来说， 预研发产品开发是制造企业对前沿技术或工艺做研究性或探索性的尝试，经过一系列功能等实验验证，并根据客户（也可能是公司内部客户）或市场需求制作出样品，在展览会或目标客户处展示，测试市场反应。 预研产品代表了公司或行业的最前沿技术水平，在得到订单后进一步开发成批量产品。 由于预研产品开发交付的产品是样件，涉及的外围职能团队相对较少，比较容易组织起跨职能团队，一般由设计，仿真，测试等组成即可，产品负责人（PO）可由该产品领域业务单元客户组成员担任。 这样的规模对企业整体组织的变更度最少，阻力也相对较小，同时提高了企业新产品的更新换代速度。 在Scrum实施获得成效后，扩大“产品”定义或“产品交付”的定义，组织变革的范围也随之扩大，整个企业的灵活性，创造力随之放大。 最终做到整个系统的敏捷：从研发到批量供货。 在制造业产品开发中，利用虚拟仿真工具减少对实物测试验证的依赖是必由之路。 我们前面举的两个例子来说，如果波音公司没有在研发中使用 3DCAD 制图，很难尽早发现设计的一些问题并进行迭代。 现代的技术手段为敏捷开发提供了更多的“物理”可能性。 3D打印技术，3D扫描技术，各种仿真技术等都提供了强有力的支持（虚拟现实技术的实际运用还要等一等）。 目前还存在着仿真的建模时间较长，仿真结果的可信度等问题影响开发迭代周期，但这都不是制造业拒绝Scrum的借口。 例如，十几年前就有国外汽车零部件企业不借助商业软件实现了3DCAD模型到多体仿真模型的自动建模，将建模时间从数周减少到数小时。 产品的功能涉及很多组件，并与其它功能相互交织，功能之间的接口不易定义清楚 机械产品中每个功能都可能会影响到所有其他功能。 功能间耦合度高。 而在软件开发中，可以从几个功能和一个简单的产品开始, 然后再陆续发布新的功能和更新产品。 这对于机械开发是不易实现的。 表面上可能会给产品待办列表（Product Backlog）的拆分以及各Scrum团队的协作带来困难。 实际上，这是个研发思路问题，是设计理念问题。 只有对某个研究对象能进行充分的“解耦”，我们才能说了解了这个对象。 如果我们设计的产品系统难以被“解耦”，说明最终产品的某种“健壮性”（robust）会有问题。 这点和软件设计开发没有本质区别。 解决这个问题需要工程实践，在初次采用Scrum框架时，会花费团队意想不到的的时间去定义Sprint的任务和测试方法，这很正常，因为我们现在使用不同的思路和角度去理解产品， 现在我们不再是以产品本身功能实现的角度，而是以面向客户、产品价值的角度审视我们的产品。 产品开发需要的外部协作较多，共享资源多，接口多 实体对象的开发需要采购，核算，样件，测试，物流，质量，生产等部门以及外部供应商们的协作。 各职能部门由于人员，设备的限制，资源由各开发项目共享。 你的项目任务是公共职能部门手里众多项目中的一个，灵活性受到限制。 如图5所示，是汽车零部件企业典型的组织架构。 图5.当前普遍的组织架构 其实，大型软件开发也会遇到同样的问题。 不同的是制造业设备资源等投资大，需要考虑共享。 但软件行业不少用于开发的商用软件价格也不菲。 共享部门的支持，外部协作不可避免。 如何解决是具体方法问题而非Scrum框架问题。 制造业完全可以借鉴软件行业的经验，做些适应性调整。 如果很难做到真正的跨职能团队，必须使用公共资源的时候，可以考虑软件业使用的“打桩”（mock-up）的方法，在迭代中尽量降低依赖度。 制造业也经常使用所谓的“Dummy”来暂时替代还没有完成的部分，以保证研发的持续，随着其他部门工作的推进，缩小被设置 Dummy的部分的规模，直到彻底取消。 团队异地合作 Scrum强调团队要在同地点工作以方便随时沟通，但如今跨国合作进行产品开发很普遍，这在软件行业也非常常见，但在机械制造行业异地团队合作的难度更大。 实践经验告诉我们，如果一个Scrum团队有异地成员，一般Sprint的长度不易定义偏短，尽管有视频会议，联合开发平台的支持，用于沟通的时间要大幅增加。 有时实物异地运输时间也要考虑在内。 4总结 为了提高企业的市场竞争力，制造业的产品开发完全可以运用敏捷Scrum框架以改变由来已久的传统模式。 实践Scrum需要结合自身的具体情况，在深刻理解敏捷理念的基础上灵活地做探索性的调整。 在实践中，最大的阻力是组织内的传统理念，从业人员的理念，而非其他技术性问题， 至上而下的推动是必要的。 作者认为，组织的机制是决定敏捷Scrum成败的关键。 作者提倡首先在产品先期研发项目上实践敏捷Scrum，然后逐步推广到整个产品开发。 由于制造业开发的对象是“实体”，生产最终产品的代价高，因此更需要在资金大投入前利用Scrum框架下的迭代增量的方法充分验证产品的市场价值，加大虚拟，快速成型等手段在研发阶段的应用力度。 在虚拟仿真和快速成型技术日益成熟的今天，机械产品开发和软件开发的差别越来越小。 参考文献 1.熊光楞主编. 并行工程的理论与实践. 2012. 清华大学出版社 Shukla, Wikispeed. Institute of Management, Ahmedabad, India, prepared this case study as part of his doctoral dissertation. () Larman and Bas Vodde. 2016. Large-Scale Scrum: More with LeSS 大规模Scrum大规模敏捷组织的设计. 肖冰 译.2018. . 2012. Essential Scrum -A practical guide to the most popular agile process. Addison-Wesley. 文章审核：Jim Wang王军版权所有，反对抄袭，欢迎转发。

瀑布式开发和敏捷开发的具体区别是什么？

敏捷开发，首先把客户最关注的软件原型先做出来，交付或者上线，在实际场景中去修改弥补需求中的不足，快速修改，再次发布版本。 再次上线或者交付。 通过一些敏捷实践方式，细化story，可以提供更小的迭代。 如此循环，直到用户（客户）满意。 适用于需求不明确的项目、创新性的项目或者需要抢占市场的项目。

瀑布式开发，要求明确的需求，大家按照需求一步步做好规划，在项目运作过程中严格产出各种文档，按着流程一步步走下去。这种模式一般适用于需求比较明确、toB端项目

但总的来说，在现在管理项目过程中，并没有严格的按照完全的敏捷或者完全的瀑布模式，都是各自掺杂了其他的方式。 在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多起一个参考作用。

瀑布项目管理和敏捷项目管理

大家现在所在的公司，是采用瀑布项目模式进行产品开发，还是选择了敏捷项目管理？今天想和大家聊聊这个话题，因为近期公司开始了数字化发展，降本增效成为日常工作的重点，对IT部门和产品部门也进行了一系列改革升级。 其中，学习敏捷并将其融入现有工作流程成为了一项重要任务。 我作为敏捷金种子，参加了公司聘请的华为导师的敏捷培训，包括项目实操，现在想和大家分享一些学习心得。 下面我们来了解一下常用的开发模式：瀑布模式（Waterfall Model）、螺旋模式（Spiral Model）、敏捷模式（Agile Software Development）、迭代模式（Iterative Model）。 今天主要介绍瀑布模式和敏捷模式，因为这两个模式与我们目前的工作紧密相关。 先来看看这两种模式的具体定义：瀑布模式：在瀑布式项目管理中，项目的整体管理过程是线性的，就像瀑布的水流落下一般，一项任务必须在下一项任务完成之前完成。 从项目规划、项目设计，到项目测试，再到项目交付，每一个环节都紧密相连，缺一不可。 敏捷模式：敏捷项目管理是一种基于增量、迭代的开发项目管理方式。 将大型项目分解为更小的、可管理的开发周期，称为「Sprint」。 项目团队再分成更小的独立团队来完成这些「Sprint」。 接下来，我们来谈谈这两种模式的优缺点和误区。 瀑布模式：作为经典的软件工程实践模式，瀑布模式体现了软件设计最朴素、最本质的核心过程。 瀑布模式并非过时，而是现代软件开发过程的核心方法论，经过不断调整依然在实际工作中被大量使用。 敏捷模式：敏捷模式只是一个理念，其中包含了若干实践方法论，如Scrum和Kanban（一种适用于人力、财务、投资等领域的轻量级项目管理方法论）。 敏捷和瀑布并非对立关系，在实践中完全可以融合使用。 例如，在新系统研发过程中采用瀑布模式，在版本稳定后进行持续迭代时则可以采用敏捷模式。 在实践中，没有任何一种软件研发模式适合所有团队和发展阶段，最佳实践永远是经过摸索后多模式的融合和共存。 决定使用什么模式时，以下因素可以参考：起初，公司大部分人对试点敏捷表示排斥，认为工作量会增加，流程更加复杂。 但开始使用敏捷后，发现效果非常不错，后面会和大家分享如何使用敏捷模式进行开发。 今天的分享就到这里啦~世事茫茫，光阴有限，算来何必奔忙？人生碌碌，竞短论长，却不道荣枯有数，得失难量。 欢迎大家关注猫幺幺，希望陪伴大家一起成长！

---

---

相关标签： 从瀑布式到敏捷式、 瀑布从远到近、 持续化集成的转型之旅、

上一篇：持续化集成与部署加快软件发布的速度和可靠

下一篇：自动化软件交付利用持续化集成提升生产力自