第八组Postmortem事后分析

Posted 2020-12-27 nowarningnoerror

第八组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最多。