PM系列之敏捷开发VS瀑布开发(一)

134 阅读3分钟

1. 敏捷开发 Scrum

敏捷开发特点是软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,能可视、可集成和可运行使用。 换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

敏捷开发特点是以用户的需求进化为核心,把任务细粒度化,基本上一个周期划分为一周两周,采用迭代、循序渐进的方法进行软件开发。优点是能更快交付、风险更低、持续改进、用户满意度更高。 但也有不足,例如无法保证最后项目的终点、初期很难进行准确的资源规划等。

2. 瀑布开发 WaterFall

瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。 衡量进度是按照步骤来的,例如需求规格、设计文档、测试计划和代码审阅等等。

瀑布开发存在主要的问题是,严格分级导致自由度降低。项目早期的计划应对后期需求的变化难以调整,并且代价高昂。这种一般适用于需求明确,后期修改不多的情况。(例如toB项目)

总之,瀑布开发在每个阶段无法回溯,一个阶段进入到下一个阶段后不能回去,流程比较重。如果后面有需求修改,则需要变更管理等一系列复杂流程。

3. 游戏开发中应用

实际游戏开发中,工期紧、需求不明确的现象很常见。项目要求尽早交付并且方便后面迭代修改,因此敏捷开发更适应游戏行业的特性。它能很快获得玩家的反馈,使开发方向能更加贴进玩家期望,具有较快的交付可用价值,提升玩家满意度。

开发过程中,流程大致划分成:文档制作->程序制作->QA测试->策划体验->外放。如果策划在上线前体验发现制作效果和当时预期表现不一致,或者设计想法有变动,有可能做需求修改。如果用瀑布开发模型,那么改动困难,极可能会耽误工期,交付风险变大。

实际上,往往是先将一个玩法或者核心功能外放上线,跟踪观察线上运行情况,结合玩家的反应和策划的预期,再决定是否进行迭代开发。如果需要进行迭代修改,则在后续交付的版本中外放。

以下是大话西游2某个版本关于新版客户端的公告。先推出了新版客户端,再进行了部分功能迭代优化。

新版客户端公告.jpg