【摘要】：本文介绍并分析了目前应用最广泛的两种开发模型(瀑布式开发模型和敏捷开发模型),再次基础上,探讨了在中小型企业在产品开发过程中如何使用这两种开发模型以达到最适合的项目管理方法,从而充分发挥瀑布模型的严谨、以及敏捷开发速度快等优点。最后,对建立完整、可操作、动态灵活的产品开发项目管理体系提出了具体的操作建议,并通过实际操作的流程验证了方法的优越性,证明了本方法设计合理,具有可用性强的特点。

浏览器类型：Chrome浏览器

了解华为软件开发云的服务功能，分析其优缺点；

瀑布化开发到敏捷开发的转型分析，以及未来软件开发模式的发展方向；

定位：软件开发云（DevCloud）是集华为研发实践、前沿研发理念、先进研发工具为一体的研发云平台，面向开发者提供研发工具服务，让软件开发简单高效。

产品slogan：云智软件 众享未来

产品关键字：（从各服务网页源码中提取）项目管理服务，云端项目管理，项目外包协作、配置管理，代码托管服务，跨地域协同开发、代码检查服务，代码质量管控，多语言代码检查、编译构建，开发编译构建，混合语言构建平台、部署管理_软件开发云_华为企业云、测试管理服务，测试解决方案，产品用例设计，测试活动管理、发布管理服务，软件仓库，软件快速发布、流水线_软件开发云_华为企业云

软件开发云为to B 平台，主要面向具有开发业务的技术团队、组织或个人。

高鑫，某二线城市创业公司的技术总监，从事软件开发行业10余年，主要做软件外包（包括web端和APP）。带着20人的技术团队，由于项目多且复杂，且多项目同时进行，成员沟通协作困难，各工作项的进度不好掌控，用传统的Excel+通讯软件工具已无法满足现有的需求，目前团队内部迫切需要一款项目管理类软件来管理项目。

1.华为软件开发云首页

首页展现了该租户下的所有项目以及工作项进度，右侧包括企业成员管理和项目最新动态消息，整个界面来看，比较简洁、而且所有工作项，包括进度的查看，拖拽改变相应的进度，也方便管理人员对所有任务的掌控和跟踪；

点击工作项可以查看工作项的具体信息，以右侧的弹窗形式弹出，可以更改相应信息和字段；

点击单个项目卡片，左侧是开发云所有端到端的功能菜单，右侧上方是以敏捷开发的理念内置测3个迭代周期，开发人员和项目经理可以根据自己的需求更改相应的迭代时间（一般为2-4周，系统会自动内置三个迭代），右侧下方是几个多维度报表，包括燃尽图（已完成工作线、未完成工作项和完成工作的趋势走势）、工作项完成率、项目需求统计、遗留缺陷统计和项目成员管理；

燃尽图，以迭代周期为横轴，工作量的数目为纵轴，绘制整个项目的进展趋势；

工作项完成率，以环形报表显示story、bug、task工作项各阶段的完成率；

根据项目管理者自定义的多个模块，以表格的形式展现不同模块在不同阶段的工作项的数量；

在最底部可以看到该项目的所有成员，以及成员所具有的权限，右侧可以添加新成员（这个才是真正意义上的成员管理）；

选择添加成员可以选择本企业的用户（多租户）、其他企业的租户、以及从其他项目中导入用户，作为企业管理者可以为企业创建用户，“点击这里”可以指导用户添加成员；

选择成员确认后，默认是开发人员的权限，点击“查看更多”，才可以修改成员对应权限；

项目角色分为项目经理、开发人员、测试经理、测试人员、浏览者；

各个角色的权限说明没有在这里显示，在帮助中心可以查到；

项目创建者可以把项目整体规划架构以思维导图（Xmind）的形式规划出来，架构深度为3层，分别为epic（大粒度的需求）、feature（中粒度的需求）、story（小粒度的需求）。

项目规划好的需求会自动在任务栏中的epic、feature、story中生成。

在backlog界面的顶部，结合了一系列操作，搜索、新建工作项、按标签查询、导入工作项、导出工作项、以及过滤功能；同时还提供了两种展现方式。一种是以列表的形式展现，另外一种是以涂鸦的卡片形式进行拖拽；

新建工作项，填写具体的字段，工作项类型可选需求或Bug ,同时系统内置了需求和缺陷模板。

导出工作项可以将每个工作项的具体字段导出到Excel中，方便数据的迁移；

卡片显示方式下，可以手动拖拽到不同进度；

更改迭代的方式，可以在具体的需求详情中更改，也可以在列表中拖拽到右侧的迭代列表；

同时工作项提供成员讨论功能，方便成员沟通协作，信息对称，另外工作项和代码之间也可以互相关联；

迭代页面则可以显示处在不同迭代下的工作项，具有工作项的迭代不能改变起止时间；

文档功能是开发云内部的FTP，项目相关文档、图片等文件可以上传到云端与成员共享；

单个文件不能超过20M ;

百科功能（wiki），内部知识库，成员可以把项目相关词汇添加进来以供成员学习分享；

项目管理服务的优点和缺点：

1.从项目规划到工作项的创建和分配，包括拖拽式的进度控制，全流程清晰明了，易于管理人员操作和掌控；提供个人级、项目级看板，直观呈现进展与风险；树表、任务墙视图满足不同用户的使用习惯；

2.整个流程基于敏捷开发的理念，采用小步快跑的迭代形式，取代传统的瀑布模式开发模式，快速应对多变的需求；

3.涂鸦式的项目卡片风格，有效提升项目辨识度；

4.提供社交化协作，多角色跨地域系统开发效率高；

5.项目文档可以系统开发、轻松共享，狗狗做任务讨论结果自动归档，有效记录工作事项；

1.新建工作项，填写具体的字段，工作项类型可选需求或Bug ,系统内置了需求和缺陷模板，暂时不支持自定义导入模板，同时该文档也无法被导出，只能在云上查看；

2.在最小粒度的backlog中，新创建的工作项不能反向关联到项目规划中；

目前业界主流的开发模式有两种，一种是瀑布模型，一种是敏捷模型，华为软件开发云是以敏捷开发（scrum流程）进行管理和开发。

瀑布模型，是一种比较老旧的软件开发模型，1970年温斯顿·罗伊斯提出了著名的“瀑布模型”，直到80年代都还是一直被广泛采用的模型。

瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。

瀑布模型优点是严格遵循预先计划的步骤顺序进行，一切按部就班比较严谨。

瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：

1.各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；

2.由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；

3.早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

4.各个软件生命周期衔接花费时间较长，团队人员交流成本大。

5.瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

那么什么是敏捷开发模式，相比于瀑布开发有什么优势？

敏捷开发模式，是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意

2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

3.经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。

4.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

5.工作的软件是首要进度度量标准。

6.敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

7.每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

华为软件开发云（以下称为Devcloud）平台的看板、迭代、多项目需求、缺陷管理等功能支持敏捷的开发模式，加强团队成员之间的协作和沟通，使项目成员更专注于业务本身，而非文档的管理；另外Devcloud贯穿于软件开发的全生命周期，基于Devops的开发理念，自动化的集成构建，运行和维护、使得团队可以快速交付一个可独立运行的项目，快速应对市场和需求的变化，让整个开发流程更加的简单高效。

目前来看，Devcloud的项目管理服务仍然有继续改进和升级的地方，但是敏捷开发、devops等理念是整个软件行业的大趋势，Devcloud也在践行这样的理念，让这些理念真正落地。

至于未来软件开发模式的发展方向，很难说敏捷开发是未来的主流模式，但是未来的需求、市场是多变的，做好功能的同时，做好用户体验，快速推陈出新，快速试错和迭代，才能保证产品的良性发展。

下一步我会继续将华为软件开发云的其他功能测试发给各位分享。

软件开发是一种对人类智慧的管理，对人大脑思维的“工厂化”管理。人是有感情的、有情绪的、变化的、相对独立的工作单元，这与冰冷的机器是不可比的，所以在中国的历史上，管理人是最难的工作；“学而优则仕”的观点就是让最聪明的人应该选出来做官，做官就是管理人的。软件开发不仅是代码编程，而是人员的有效组织，如何既发挥人的主观能动性，避免情绪变化对工作的影响，又可以让大家有效的交流，让多个大脑的思路统一，快速完成目标呢？多年来软件企业的管理者一直在不断地探索。

另外有一个问题一直是软件开发管理人员的心病：软件是工具，开发的是客户业务的应用，但客户不了解软件，开发者不了解业务，如何有效沟通是软件质量的重大障碍。把开发者变成客户业务的专家是个没有办法的办法，让软件企业付出的代价也是昂贵的。

瀑布模型、极限编程、敏捷开发是有代表性的开发模式，在对开发者、客户、最终的产品的关注上的变化，体现了软件开发管理者在管理模式上的变化。

Model)是Royce在1970年提出的，他把大型软件开发分为：分析与编程，象工厂流水线一样把软件开发过程分成各种工序，并且每个工序可以根据软件产品的规模、参与人员的多少进一步细分成更细的工序。该模型非常符合软件工程学的分层设计思路，所以成为软件开发企业使用最多的开发模型。

瀑布模型的用户很多，也有一些反对的意见：

第一、瀑布模型不适合客户需求不断变化的软件开发，尤其是客户的业务管理的软件，业务随着市场变化，而软件初期的设计可能已经大大变化，而后期的需求更改成本是开始的10倍基数。在ERP盛行的软件市场里，一方面市场带动需求变化，另一方面初期客户对需求描述不清楚，都为瀑布模型的使用团队带来困难。

第二、瀑布模型是一种软件文档的开发，把开发者变成流水线上的机器，大量重复性的工作让编程人员提不起兴趣，工作很枯燥，没有激情，编程成了一种没有创意的机械劳动，这让一向以高科技为标志的高级程序人员大为恼火。

极限编程诞生于一种加强开发者与用户的沟通需求，让客户全面参与软件的开发设计，保证变化的需求及时得到修正。要让客户能方便地与开发人员沟通，一定要用客户理解的语言，先测试再编码就是先给客户软件的外部轮廓，客户使用的功能展现，让客户感觉到未来软件的样子，先测试再编码与瀑布模型显然是背道而驰的。同时，极限编程注重用户反馈与让客户加入开发是一致的，让客户参与就是随时反馈软件是否符合客户的要求。有了反馈，开发子过程变短，迭代也就很自然出现了，快速迭代，小版本发布都让开发过程变成更多的自反馈过程，有些象更加细化的快速模型法。当然极限编程还加入了很多激励开发人员的“措施”，如结队编程、40小时工作等。

极限编程是一种开发管理模式，它强调的重点是：

1、              角色定位：极限编程把客户非常明确地加入到开发的团队中，并参与日常开发与沟通会议。客户是软件的最终使用者，使用是否合意一定以客户的意见为准。不仅让客户参与设计讨论，而且让客户负责编写拥护故事(User Story)，也就是功能需求，包括软件要实现的功能以及完成功能的业务操作过程。用户在软件开发过程中的责任被提到与开发者同样的重要程度。

2、              敏捷开发：敏捷开发追求合作与响应变化。迭代就是缩短版本的发布周期，缩短到周、日，完成一个小的功能模块，可以快速测试、并及时展现给客户，以便及时反馈。小版本加快了客户沟通反馈的频率，功能简单，在设计、文挡环节大大简化。极限编程中文挡不再重要的原因就是因为每个版本功能简单，不需要复杂的设计过程。极限编程追求设计简单，实现客户要求即可，无需为扩展考虑太多，因为客户的新需求随时可以添加。

3、              追求价值：极限编程把软件开发变成自我与管理的挑战，追求沟通、简单、反馈、勇气，体现开发团队的人员价值，激发参与者的情绪，最大限度地调动开发者的积极性，情绪高涨，认真投入，开发的软件质量就大大提高。结对编程就是激发队员才智的一种方式。

    极限编程把软件开发过程重新定义为聆听、测试、编码、设计的迭代循环过程，确立了测试->编码->重构(设计)的软件开发管理思路。

极限编程的12个实践是极限编程者总结的实践经典，是体现极限编程管理的原则，对极限编程具有指导性的意义，但并非一定要完全遵守12个实践，主要看它给软件过程管理带来的价值。

1、              小版本。为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。

2、              规划游戏。就是客户需求，以客户故事的形式，由客户负责编写。极限编程不讲求统一的客户需求收集，也不是由开发人员整理，而是采取让客户编写，开发人员进行分析，设定优先级别，并进行技术实现。当然游戏规则可进行多次，每次迭代完毕后再行修改。客户故事是开发人员与客户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的、沟通顺畅的。

4、              隐喻。隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此开始要先明确双方使用的隐喻，避免歧异。

5、              简单设计。极限编程体现跟踪客户的需求变化，既然需求是变化的，所以对于目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，增加了软件的复杂度，开发的迭代周期就会加长。简单设计包括四方面含义：1、通过测试。2、避免重复代码。3、明确表达每步编码的目的，代码可读性强。4、尽可能少的对象类和方法。由于采用简单设计，所以极限编程没有复杂的设计文档要求。

6、              重构。重构是极限编程先测试后编码的必然需求，为了整体软件可以先进行测试，对于一些软件要开发的模块先简单模拟，让编译通过，到达测试的目的。然后再对模块具体“优化”，所以重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学”的一个概念，是在不影响物体外部特性的前提下，重新优化其内部的机构。这里的外部特性就是保证测试的通过。

7、              测试驱动开发。极限编程是以测试开始的，为了可以展示客户需求的实现，测试程序优先设计，测试是从客户实用的角度出发，客户实际使用的软件界面着想，测试是客户需求的直接表现，是客户对软件过程的理解。测试驱动开发，也就是客户的需求驱动软件的开发。

8、              持续集成。集成的理解就是提交软件的展现，由于采用测试驱动开发、小版本的方式，所以不断集成(整体测试)是与客户沟通的依据，也是让客户提出反馈意见的参照。持续集成也是完成阶段开发任务的标志。

9、              结对编程。这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程，一个编码，一个检查，增加专人审计是为了提供软件编码的质量。两个人的角色经常变换，保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。

11、           编码标准。编码是开发团队里每个人的工作，又没有详细的文档，代码的可读性是很重要的，所以规定统一的标准和习惯是必要的，有些象编码人员的隐喻。

极限编程的思想体现了适应客户需求的快速变化，激发开发者的热情，也是目前敏捷开发思维的重要支持者。

2001年，17名编程大师分别代表极限编程、Scrum(“棒球”团队开发模式)、特征驱动开发、动态系统开发方法、自适应软件开发、水晶方法、实用编程等开发流派，发表“敏捷软件开发”宣言。敏捷软件开发是一个开发软件的管理新模式，用来替代以文件驱动开发的瀑布开发模式。敏捷方式也称轻量级开发方法。敏捷软件开发宣言内容：

敏捷开发集成了新型开发模式的共同特点，它重点强调：

3.         客户与开发者的关系是协作，不是合约。开发者不是客户业务的“专家”，要适应客户的需求，是要客户合作来阐述实际的需求细节，而不是为了开发软件，把开发人员变成客户业务的专家，这是传统开发模式或行业软件开发企业的最大面临问题。

4.         设计周密是为了最终软件的质量，但不表明设计比实现更重要，要适应客户需求的不断变化，设计也要不断跟进，所以设计不能是“闭门造车”、“自我良好”，能不断根据环境的变化，修改自己的设计，指导开发的方向是敏捷开发的目标。

敏捷开发避免了传统瀑布方式的弊端，主要是吸收了各种新型开发模式的“动态”特性，关注点从文档到开发者，管理方式也从工厂的流水线到团队的自我放松式的组织。总结敏捷开发与瀑布模式的不同，主要是下面几个“敏捷”的关注点：

?        客户参与。以人为本，客户是软件的使用者，是业务理解的专家，没有客户的参与，开发者很难理解客户的真实需求

?        小版本。快速功能的展现，看似简单，但对于复杂的客户需求，合理地分割与总体上的统一，要很好地二者兼顾是不容易的。

敏捷就是“快”，快才可以适应目前社会的快节奏；要快就要发挥个人的个性思维多一些，个性思维的增多，虽然通过结队编程、代码共有、团队替补等方式减少个人对软件的影响力，但也会造成软件开发继承性的下降，因此敏捷开发是一个新的思路，但不是软件开发的终极选择。对于长时间、人数众多的大型软件应用的开发，文档的管理与衔接作用还是不可替代的。如何把敏捷的开发思路与传统的“流水线工厂式”管理有机地结合，是软件开发组织者面临的新课题。