码迷,mamicode.com
首页 > 其他好文 > 详细

第八组Postmortem事后分析

时间:2018-08-02 22:46:10      阅读:136      评论:0      收藏:0      [点我收藏+]

标签:lin   nts   class   tom   集中   艺术   work   改进   游戏   

第八组Postmortem事后分析

一、团队成员总结的改进和教训

    隆晋威:Beta阶段完善架构设计,分工更加明确,文档更丰富,交流带来开销减少。Alpha技术选型不固定,分工混乱,没有方便的测试引擎,部分模块耦合严重。

    付千山:Alpha阶段工作较少,主要进行技术积累,由于考试,工作进度稍慢;Beta阶段学到了很多东西,debug能力大大加强,Commit数量、代码量及处理问题的经验积累也有所提高。

    欧阳炳濠:Beta阶段中,不同于Alpha阶段。Alpha阶段中主要做的是游戏界面的基本逻辑功能能够实现,但是有许多漏洞,而且玩家体验的效果也不佳,缺乏提示性语句,使得未接触过游戏的玩家对于游戏内发生了什么,该怎么做,完全不知道。而且缺乏封闭性的设置,使得游戏很容易崩溃。

    所以在这次Beta阶段的开发中,着重在提升玩家的用户体验。我在这次优化中,找美工同学帮我们重新画了一张地图,同时还增加了消息框功能,用于让所有玩家知晓游戏局势。除此之外,我还设计了玩家在移动后,地图自动跟随玩家移动的功能,便于玩家快速找到自己的位置,而且隐藏了地图的滑动条,使画面更为美观。除此之位,设计了悬浮窗口功能,当玩家将鼠标放置在某一个玩家的人物上时,就能出现显示该玩家的状态信息窗口,包括身份、生命值、英雄、射程、火力、机动性等。便于玩家在游戏中对局内情况进行博弈。

    总而言之:在Beta阶段中,打破了信息交流的堡垒,优化了界面的风格,增加新用户的友好性,增强游戏的稳定性,改善玩家的游戏体验。

    吴宏宇:Alpha版本中主要是学习新的技术与框架,再一次次的失败中吸取教训与经验,提高自己在团队中的工作效率,改善自己的开发习惯,总的来说就是在开发中提炼自己;beta版本的开发注重了各类的细节,不再是摸着石头过河,而是有准备的进行工作,在之前的版本下不断完善存在的缺陷,总的来说就是要以用户的角度开始提高他们的体验。

    朱池苇:Alpha阶段初期对使用的模型和框架比较陌生,用了较长时间学习和实践。Beta阶段,技术已经较为熟练,能够不需要他人协作完成本部分的工作,效率得到了提升,且加深了对模块化的编程方法的理解。

 

二、关于敏捷开发

    ① 做的最好的两点

     (1)经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。(Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.)

     我们的Alpha版本产出较早,虽然非常简陋,而且爆破测试也无法通过,但是有了这个框架,我们在后续阶段的发挥就有了基础。

   (2)不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。(The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.)

    本团队开会较为频繁,在非考试周保证了每周2-3次面对面会议,即使是在考试周也有每周一次的集中。这使我们解决问题的效率和效果比较好。

    ② 做的最差的两点

  (1)欢迎需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。(Welcome changing requirements, even late in development. Agile processes harness change for the customer‘s competitive advantage.)

    由于游戏开发的初衷是“我们想做一个这样的游戏”,向客户征求的大多是细节问题。而且电子游戏,必须要作出原型,才能收获用户的反馈。因此我们在很长一段时间内,用户调研的方式都是线下使用纸张和卡牌做成的桌游版,请桌游社的同学进行评测(测评反馈较为积极,同学也针对游戏提供了宝贵的建议和意见)。在集中精力开发的一段时间内,与用户也有所脱节。

  (2)以简洁为本,它是极力减少不必要工作量的艺术。(Simplicity--the art of maximizing the amount of work not done--is essential.)

    由于技术设计的问题,我们在某些细节上的处理有一些冗余,甚至是dirty,这也是我们将一直致力于改进的问题。

 

三、关于“大教堂和集市”开发方式

     本组在刚起步阶段时,为集会模式,所有人都可能会接触到所有代码并进行修改,而在技术选型确定,掌握情况较好之后,则按照各自的分工进行工作,不再互相干涉,因此变为大教堂模式。

     我们的体会是,大教堂开发模式更适合管理,而在项目规模较小的时候,或者项目刚开始的时候,集市更适合,因为那个时候需要创意,且BUG最多。

第八组Postmortem事后分析

标签:lin   nts   class   tom   集中   艺术   work   改进   游戏   

原文地址:https://www.cnblogs.com/NoWarningNoError/p/9409735.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!