计算机诞生的几十年来,人们已经提出许多改进软件开发过程的方法。每一种方法都被吹捧为“重大成果性突破”,每一种方法都声称“使过程可控”。其实笔者认为,他们这些方法没有一种做到上述两点,管理混乱的软件开发过程仍然随处可见,投入越来越多的人力、财力,所有人都变得疲惫不堪,但是整个项目却在进度的泥淖中越陷越深。正如Grady Booch所说的:“我们常称这种情况为软件危机”。但坦率的说,长久以来我们一直把这种病态看作是正常的。?在游戏行业,推迟发布已成为家常便饭,还有不知多少游戏项目胎死腹中。
在盗版横行,软件开发商和发行商举步维艰的环境中,在线游戏领域成为为数不多的赢利领域之一。而大型多人在线角色扮演游戏(MMORPG, Massively Multiplayer Online Role Playing Game)以项目风险高,开发难度大,利润丰厚这三大特定更是成为了游戏领域关注的焦点。
对程序员来说,MMORPG开发的难度在哪里?笔者认为最大的难度来源于需求变化大,“变化”贯穿了整个开发周期,甚至运营期,且这种需求的变化很难预测。作为游戏开发中需求的提出方,策划的想法非常多样。为了吸引玩家,他们不得不绞尽脑汁,想出各种新鲜的玩法来。而这些玩法,可能需要非常多程序员和美术师的配合工作才能完成,所谓“策划动动嘴,程序跑断腿”的说法在业内流传甚广,可以从一个侧面反应出这个现状。即使在游戏运营以后,仍然可能有新的需求,很难想像一个在中秋节、元宵节不能推出适宜活动的网络游戏;一直没办法推出新版本去解决游戏中不平衡问题,程序漏洞(这是不可避免的)等问题的网络游戏;一直不能推出资料片和新玩法的网络游戏能够获得玩家的青睐。为了获得竞争的优势,游戏必须不停的更新,改进旧有的玩法并且加入新的玩法,而这些游戏本身具有的开发特性给程序员开发带来最不同于开发传统软件的困难。
敏捷开发——快速的响应变化
Scrum开发方法是由Ken Schwaber和Jeff Sutherland提出,名称来自英式橄榄球,在比赛中每个队员都应时刻保持对场上全局的判断,然后通过集体的快速行为,奋力实现同一个目标——胜利。Scrum能够快速响应需求的变化,Scrum的这一特性适合于开发MMORPG。 使用Scrum开发软件就像开发新产品,过程中需要研发、创意、尝试错误,所以无法从一开始就定义软件产品最终的规程。Scrum 将软件开发团队比拟成橄榄球队,有明确的最终目标,需要程序员熟悉开发流程中所需具备的最佳工具与技术,程序员具有高度自主权,紧密地沟通合作,以高度弹性解决各种挑战,分阶段的将目标划分为具体而细小的任务,快速不断的将可以执行的版本交付最终用户,确保每天、每个阶段都朝向目标有明确的推进。 使用Scrum开发方法,要求知识在程序员中相互传递。在一个Scrum小组里面,没有绝对的权威,每个人都是某一方面的专家,通过结对编程或者其它的办法,促进知识的交流。结对编程是近来很流行的一个作法,笔者甚至见过令人感觉最不可思议的办法——一个程序员控制鼠标,而另外一个程序员控制键盘。在Scrum开发的过程中,每个程序员额外的任务是向同组成员传授自已的技术特长,而这么做最终的目的并不是将每个程序员都培养成面面俱到的专家,而是希望他们在技能方面能够一专多能,即对一个方向非常精深,对项目相关的其它方面也有一定程度的了解,或者我们也可以把他们称为“准专家”。这样做的好处是,在确定具体的技术方案时,游戏相关方方面面的人员更容易达成一致的意见。 使用Scrum开发方法,要求轮换的进行结对编程。每个人都与组里其他所有的人结对编程过,轮换的周期不一定,可能一周,可能一次迭代开发周期,具体要视项目的情况而定。
Scrum的任务分解
在Scrum中,Backlog指可以预知的所有任务,包括功能性的和非功能性的所有任务。Scrum的一个开发阶段开始时,项目经理、策划、程序坐在一起,由策划提出任务,项目经理和程序员协商,选择这一阶段应该完成哪些任务。从程序员的角度考虑,优先选择容易完成的任务,把难于实现,耗时巨大的工作放在后面。在设计和实现时,不进行任何宏大的设计,使用最简单直白的办法,只要能够达到目标——将带有该功能的可执行版本交付给用户即可,不为所谓“将来可能的需要”做额外的工作,避免过度设计的问题。使用重构的办法来改善软件内部的结构,重构是随时随地都在进行的。 我们可以使用一些软件工具来管理Backlog,比如Microsoft Project或者WIKI,甚至是论坛也可以,Backlog的管理软件可能需要能够进行优先级排顺,为其指定起止时间,添加评注等功能,这些也可以通过扩展软件进行操作,或者通过会议的形式在团队内部达成协议。这无关紧要,只要大家用起来觉得方便即可。记住,Backlog是所有人都可以看到的团队目标。
SCRUM的迭代周期
Sprint指一次迭代开发的时间周期,一般在30天以内。在这段时间内,开发团队需要完成一个制定的Backlog列表,最终成果是一个增量的、可以运行的版本。在英式橄榄球中,Sprint是指拿到球加速跑。这里的喻意是,开发团队得到目标(Sprint Backlog)后,全力向目标冲刺。 有时在需求的提供方“策划”和需求的实现方“程序员”之间会存在一个“缝隙”,即两者对需求的理解有所不同。Sprint通过快速的交付可以“看”到最终效果的版本,让双方对最终的效果有个直观的了解,以达到弥补这一缝隙的目的。 在一个Sprint期间,不再对这一Sprint的Backlog进行变动,也不再新增加Backlog。如果有新的Backlog,则放到下一个Sprint完成。如果功能变动大到一次Sprint的成果基本无效时,那么则取消这个Sprint。Sprint可以新建和删除,但是不可以修改,必须保证程序员的目标在一个阶段内不发生变化,否则将导致程序员不知所措,或者Sprint的周期不断被延长。