Scrum 开发模式在多媒体播放软件开发行业的应用研究

Posted 2021-04-25 IT项目管理界

摘要：当前， 在国内的多媒体播放软件开发行业中通常存在着以下问题，产品不能按时交付，交付的产品质量出现问题需要返工，客户满意度低，开发过程中很少有迭代与客户反馈，后期变更的成本太高，测试与文档开发人员在项目前期的利用率低，后期却加班频繁等，这种种的不利因素对于稳定产品质量的带来了极大的隐患与风险。因此，有必要对于国内的多媒体播放软件开发项目进行项目管理上的改进。本文将首先分析当前多媒体播放软件开发行业的现状，介绍目前行业中普遍采用的项目管理方法，然后对于目前行业中在项目管理上所存在的问题，提出适合于行业的、改进的项目管理方法。

关键词：Scrum；软件开发；项目管理

1.研究背景及意义

随着多媒体播放软件开发行业的兴起，竞争也开始加剧。如何对多媒体软件开发项目的过程进行更加有效的管理，成为了摆在企业管理者面前的一道难题。在国内外大部分的多媒体播放软件开发项目中，比较多的是采用传统的项目管理模式，如瀑布模型开发模式，来进行新产品的研发工作。软件开发不仅仅是编写代码，更关系到如何有效地组织项目人员，如何高效地发挥项目人员的主观能动性，如何真正地发挥团队的力量，来快速地完成高质量的产品。因此，需要采用更加灵活有效的流程来克服这些问题和局限性。在多媒体播放开发行业的高速发展和客户需求的日益增加和变化的大环境之下，应该认识到只有先进灵活的、高效的项目管理理念，才能保证多媒体播放软件项目更加有效地开展，才能更快地发布质量更好的产品，才能占领市场的先机和优势，才能在竞争中取得胜利。

2.项目管理理论

项目管理理论是在项目过程中使用专门的技能、知识、方法和工具，对既有的资源进行合理地管理、调度和分配；通过这个过程，使得项目的完成结果可以达到或者超过项目干系人的期望和需求。为了使项目获得成功，必须对项目制定合理的计划，对可能存在的风险、所需资源、工作范围、要实现的任务、花费工作量（成本） 、进度、经历的里程碑等做到合理的安排。

2.1 什么是项目管理 项目管理[1]是指项目的管理人员， 使用特定的方法、技能和有关的理论知识，在资源限定的条件下，对项目进行有效地管理和控制。从项目的开始，直至项目的最终结束，在此过程中，通过制定计划、组织协调、领导、监控和干预，从而实现预先设定的项目目标。从本质来说，项目管理行为没有秘密，经过组织的工作和活动，都可以被认为是项目管理行为。但从近代开始，项目管理行为渐渐被提炼和发展成为了一种具备广泛科学性质的理论模式。

2.2 瀑布式开发模式理论 瀑布式开发模式是由温斯顿•罗伊斯在 1970 年提出的，直至 19 世纪 80 年代早期，它一直是仅有的被普遍使用的软件开发模型。瀑布式开发模式的中心思想是按照程序将事情由繁化简，把设计与实现分别对待。这样做的优点是方便有序地分工合作。各个活动自上而下、有序衔接，如同瀑布流水，逐级下落。瀑布式开发模式是一个开发框架，是经历一系列的阶段按顺序开展的开发过程。因此，如果在过程中有功能未被覆盖或者出现了问题，需要“返回”到上一个阶段并进行相应的修改。开发阶段从一个阶段“流动”到下一个阶段，这也是瀑布式开发模式名字的由来。

在软件工程中，瀑布式开发模式占据重要的地位，它是软件开发的基础架构。它也是软件的一种开发路线，将项目拆分为一定数量的阶段。有序执行每一个阶段，而且依赖于先前的已完工的阶段。使用瀑布开发方法的情形下，开发工作的各个部分需要区分评估，并且常常由不同的团队来实施[2]。

3.基于 Scrum 的多媒体播放软件项目管理方法设计
基于多媒体播放软件开发行业的特点，与当前模式所存在的弊病与局限性，需要针对当前模式所存在的问题，结合行业特点，改进现有开发模式的思路，研究适合于行业的、更加高效的项目管理模式，从而使开发过程更加高效，提升产品质量，提高客户满意度。

3.1 多媒体播放软件项目特点 国内的多媒体播放软件项目的特点如下：

3.1.1 项目无法按时交付 当开始一个新的多媒体软件开发项目时，由于种种原因，通常没有人会特别清楚如何才能实现它、会碰到多少技术难题、多久才能攻克、多久才能交付。这取决于项目的范围与复杂度。

3.1.2 项目工期紧，加班普遍 软件行业竞争激烈，多媒体播放软件开发行业也是如此。很多多媒体软件开发公司加班的情况非常普遍，主要原因是项目的工期紧张。一方面，如果预估的项目的最终交付时间存在偏差，项目进展滞后，那么经常需要加班赶工来追赶进度。另外一方面，在交付产品给客户后，也存在由于质量问题而返工的现象，并且客户需要在他们的 code freeze 之前修复所有的bug，这也增加了加班的现象。

3.1.3 项目人员安排的不确定性 多媒体播放软件开发项目中，具体的开发人员有自己负责的模块。比如负责图像解码的开发人员在暂时没有后续的开发任务的情况之下，会抽出身来兼顾其他的开发项目。而这样的安排所导致的后果是，当有后续的图像解码方面的工作时，该开发人员仍然在其他的项目中，项目开发进度可能需要进行时间上的调整，或者是开发人员上的调整。而由其他的开发人员接管，由于需要一段熟悉期，通常会减慢之前的开发进度。

3.1.4 需求变化多 多媒体播放软件开发项目中，需求的变更正在变得越来越频繁。这包括外部环境的变更需求与客户的需求变更。

3.1.5 所需要支持的平台、系统众多 多媒体播放软件开发项目中，需要支持跨平台，不同系统，不同设备以及不同 CPU 架构上的播放器开发。这确保了用户可以在各平台、各系统上二次开发他们自己的多媒体播放器而不用担心平台、设备、协议的局限性。

3.2 基于 Scrum 模式的项目管理方法

3.2.1 改进现有开发模式的思路 如果企业的目标是重复性的制造与生产，那么原有的传统的流程是适用的，而对于像多媒体播放软件开发这样需要不断创新、需求变更频繁、需要不断开发新产品的行业来说，原有的模式已显得过于笨重和低效，需要一个不同的、改进的模式来解决原有模式所存在的问题。

3.2.2 更改项目计划的粒度 原有模式中经常出现花了很多时间做调研和制订计划，然而还是无法按计划交付产品。这是因为多媒体播放软件开发项目中有大量的创新性工作，而这些创新性工作又没有过往数据可供参考。随着项目的进行，再对即将要做的工作、涌现的需求、需求的变更制订详细的计划，依此类推。这么做的好处在于避免了前期做很多假设来制定一个看似完整、实际不准确的项目计划[3]。

3.2.3 以迭代、持续交付的方式来工作 在改进的模式中，可以将功能模块进行划分，用一个个短周期迭代的方式来工作，在每个迭代周期结束后交付可工作的若干功能模块给客户，并获取客户反馈。项目团队总是专注于优先开发并发布对于客户高价值的功能模块，完整的功能模块是由一系列的增量产品组成的。这么做的好处在于，基于迭代的工作模式尽早交付给客户有价值的部分功能，并更早的获得客户反馈。因此，这种改进的模式避免了开发低价值或者不需要的功能模块，从而比原有模式更快的交付产品[4]。

3.2.4 更好地获取客户反馈 在改进的模式中，需要强调以人为本，鼓励让客户“参与”到项目开发中。客户是软件的最终使用者，通过更早地交付可工作的功能模块给客户，让客户可以在实际环境中运行与测试，从而尽早地获得反馈，有助于开发人员更好地理解客户的真实需求，避免了闭门造车所带来的错误。

3.2.5 组建自组织的团队并提升团队士气 在改进的模式中, 不再是项目经理分配任务给相应的团队成员，而是建立一个相对平行的组织。由于淡化了管理和被管理的组织关系，组织更加开放，团队氛围也更加和谐。这种更平等的组织结构可以促进团队成员的交流，激发开发人员的工作热情，并且提高开发效率[5]。

3.2.6 更好地处理需求变更或涌现的需求 在多媒体软件开发项目中，变更或者涌现的新需求是经常存在的。因此，改进的模式中，需要更好地处理用户需求在开发过程中的变化及时与客户沟通，必须确保在改进的模式中能够更早地知道需求变更和涌现的新需求以更好地应对所带来的影响。

3.2.7 优化测试与文档开发人员的利用率 在改进的模式中，确保项目以持续、稳定的步伐进行的情况下，保证了每个阶段都有可交付、可测试的功能模块。这种可交付、可测试的功能模块使得测试与文档开发人员可以更早地加入项目中。

4.总结与展望

基于 Scrum 的管理理念目前越来越流行，它强调了以人为核心，创造一个和谐的项目环境，激发团队成员的潜力，从而最大化团队的生产力。通过快速迭代，集中体现了其能快速适应各种变化的优势。这种理念要求客户相较以往更加频繁和更加紧密地参与到产品开发中。这可能会导致有部分客户不习惯或者不适应，因此在开发过程中需要和客户加强沟通，使客户更直观地意识到他们在产品开发中花费一定的时间参与进来可以帮助提升产品质量，产生双赢的局面。另外，目前基于 Scrum 管理理念主要是运用于软件开发项目中，相信在不久的将来会有更加广阔的发展空间。通过对个体、应用技术、资源对象的进一步研究和具体实践，基于Scrum 的管理理论会更加完善，并应用到其他领域中。

参考文献：

[1]MBA lib (wiki.mbalib.com)，项目管理：项目管理简介， http://wiki.mbalib.com/wiki/项目管理.

[2]周三多.管理学-原理与方法[M].五版.上海：复旦大学出版社， 2011.

[3]John Hunt， 《Agile Software Construction》, UK SpringerVerlag, 2010.

[4]王海鹏.软件质量改进和风险降低之道[M].北京：电子工业出版社， 2012.

[5]桑大勇，王瑛，吴丽华.敏捷软件开发方法与实践[M].西安：西安电子科技大学出版社， 2010.

本文2017年发表于《价值工程》