Postmortem Report 第一轮迭代事后分析报告
一、设想和目标
1.1 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件《BlueZ》是一款全新动作类塔防游戏。与市面上已经存在的塔防游戏不同的是，我们的塔防游戏不仅以经典的塔防游戏作为基本的游戏模式，又创新地引入了动作（已实现）、联机（将会在第二轮迭代中实现）等元素，使游戏从传统的建造防守武器，转变为自主控制游戏人物进行防御，从传统的单人作战，转变为更有趣的团队作战。游戏因此变得紧张成刺激、节奏感强，玩家在游戏中便能获得更多的乐趣与成就感。从而既解决了塔防游戏相对比较枯燥无聊被动的问题，使玩家能够乐在其中，又不会像大型游戏一样占用玩家过多的时间精力，使玩家能够张弛有度。
我们的软件《BlueZ》对我们所要解决的问题定义的非常清晰，整个一轮迭代过程中每个人都在为解决这一问题而添砖加瓦。无论是主角与敌军的工作与技能，还是地图与道具的设计，都践行了我们的目标：既不会像塔防游戏一样相对枯燥无聊被动，又不会像大型游戏一样占用玩家过多的时间精力。
我们的典型用户就是工作或者学习过程中想要放松的群体，他们只需一款可以消遣又耐玩的游戏，而我们的游戏恰好是以达成这一目标而努力的。
1.2 是否有充足的时间来做计划?
我们的团队在一轮迭代过程中用了整整两个周的时间完成调研与游戏设计工作，并且在两周的冲刺开发过程中不断完善我们的游戏设计。
但是完美的实现计划确实时间不够，因为这次毕竟是第一次团队的合作，正处于磨合期。所以效率上面不是很理想。外加除了这门课程之外还有其他的课程。所以第一轮迭代时间不是很充足。但是第二轮迭代应该就没有什么问题。
1.3 团队在计划阶段是如何解决同事们对于计划的不同意见的？
每周三晚上我们会进行例会，会上大家会将自己的想法提出，每个人对于其他人提出的想法都会认真思考分析并提出自己的建议，大家一起商讨可行性之后，对于计划的是否实施与实施程度进行决策。
在一些关键问题上面，我们采用匿名投票的方式。使得大家的意见可以完整的、无拘束的表述出来。除了开会之外，我们组建了专门的QQ群，如果有组员有什么新的想法，可以在QQ群里面快速提出，以方便对于项目决策的快速响应。我们认为这个也是敏捷开发的一个部分。
更关键的是，所有的组员都有着高度的负责精神，即使出现了什么问题，大家也会一同解决，求同存异，一切以项目优先。
1.4用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
游戏刚刚发布几天，下载量就达到了可观的60人次，这符合我们的事先预想，在进行进一步的推广工作并对游戏进行完善之后，用户量预计会持续增长。通过提供给一些用户的试玩情况来看，用户对于我们的游戏的休闲性非常满意，同时也提出了诸如增加游戏联网对战功能、增加打击感等我们早已计划在第二轮迭代中完成的工作，这与我们的预想基本一致，而相信经过第二轮的迭代，我们的游戏会更加契合用户的需求。
1.5有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在软件开发前期一定要将整个架构做好，否则在游戏整合过程中会出现各种问题，这次的一轮迭代我们的最后整合工作就花费了相关人员大量的时间与经历；每个成员的分工一定要落实到位，截止日期一定要明确，否则出现延期等情况是谁也不想看到的；团队一定要有明确的美工，否则每个人各自进行各自的美工会严重影响团队的效率，并会导致整个游戏的画风不一致等问题。
如果历史重来一遍，那么我们无疑会改进上述问题：首先是明确美工，选出最适合美工的人来专职美工，提供各种素材与修改各种素材；定义好接口，为每个人提供最适合他的分工，第一轮迭代我们为了让每个人得到锻炼而基本让每个人都完成了差不多的代码量，但不可否认的是代码的质量参差不齐，所以第二轮迭代过程中为软件的质量和了整个团队的效率，团队成员应该各司其职，适合DEV的做DEV，适合Test的做Test。
二、计划
2.1 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
对比我们最初的原计划，我们基本完成，能完成计划主要有两个原因：
（1）第一次迭代的目标设置合适
在对《Bluez》这款游戏最初策划的时候，团队中各位都对这款游戏提出了很多期望，除了最基本的设计以外，还包括地图的自动更换，瞬间转移点的设计，wifi蓝牙对战，装备系统，多种模式的设计等等，但是PM李孟（以下简称孟神）冷静思考以后，提醒大家第一次迭代的目标应该要现实一点，笔者对于这个情节记得非常清楚。在孟神提醒之后，大家都重新设计 了第一次迭代的内容，最终达到了比较好的效果。
（2）团队协作，按照时间点完成
我想，如果老师仔细看，就会发现我们团队和别的团队的最大不同就是，我们团队的scrum记录以及burndown图都是真实开发中的记录（如果你能明白我的意思），此外，我们从任务布置的当周开始就开始进行开发，而不是像其他团队等到了最后两天才忙碌起来。在整个过程中，团队的凝聚力都很强，虽然我们每个人都有很重的学业负担，但是都把软工这件事放到了很高的位置上。
2.2 有没有发现你做了一些事后看来没必要或没多大价值的事?
回顾之前，确实有一些没必要或没价值的事情。
我们在设计的时候花了太多的时间在美工上，我认为这是不必要的，虽然美工对游戏非常重要，但是作为第一次迭代开发，逻辑功能的完备才是主要任务。更何况，按照我们的实际经历，美工的工作总是被不断的否决，不断的重做，不断的p图，花了大把时间。
2.3 是否每一项任务都有清楚定义和衡量的交付件?
这一点我必须承认没有完成得非常好，在对开发的任务进行拆分以后，由于对引擎本身有很多的不熟悉，我们在划分好任务以后，并没有对每个模块进行很好的说明等，这里主要体现在我们没有给出一个很详尽的接口设计，而是采取了请熟悉游戏引擎、有多次开发经验的毛宇来在过程中协调整合。
我们有衡量交付件的标准，那就是在每个人都在最原始的框架下能够测试通过自己的模块。
2.4 是否项目的整个过程都按照计划进行?
项目在整个过程中并没有完全按照计划进行，回头一看我们的记录以及burn down图就可以看出来，过程中不断有队员有急事，或者感冒生病等。所以项目虽然整体上跟上步伐，但是细化到每一天，确实不完全按照计划进行。
我们的补救方案也很简单，那就是没有做完的工作在每天的scrum meeting上面重新分配。我也是从这个细节上深深感受到了敏捷的思想。
2.5 在计划中有没有留下缓冲区，缓冲区有作用么?
在计划中我们一直有留缓冲区的习惯，其实不仅仅是这次作业，每次任务，我们都会留下两天的缓冲区。这两天的缓冲区是有作用的，前面提到在整个过程中由于各种不可预期的事件，我们的计划会有推迟，缓冲区正是用来解决这个的。这也是为什么我们组的游戏《Bluez》是第一次迭代展示当天唯一一个完全展示出了功能的项目。
2.6 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来的计划主要会做以下几个方面的修改：
1.在实际开发中会更加注重接口定义以及单元测试。
2.缓冲区的时间需要留的更长一点，特别是在后期，还有数据库，编译大作业，大家的时间会更少，所以应该留够更长的缓冲区。
3.加强build 工程的频率，这句话其实是在<Agile Software Development> 中提到的，加强build工程的频率会更好的减少以后调试错误的时间，此外，也可以起到督促组员工作的功能。
4.任务分配更加平均：这次的任务其实有明显的不平均的情况，导致有的组员做了很多工作，有的组员做的就稍稍少了一点，之后的任务分配会更加的公平，旨在发挥每个组员的最大潜能。
2.7我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
总的来说，这次的软工，我们主要是感受了一下敏捷开发带来的高效能。记得以前做《面向对象》作业的时候，4个人开发一个很简单的软件，却由于组织方法的疲软没有很好的动员好大家，搞到最后完全没有士气来做，最后一天还在赶作业。
如果历史重来一遍，就像我刚才说的，我们会做四件事情：
1.在实际开发中会更加注重接口定义以及单元测试。
2.缓冲区的时间需要留的更长一点，特别是在后期，还有数据库，编译大作业，大家的时间会更少，所以应该留够更长的缓冲区。
3.加强build 工程的频率；这句话其实是在<Agile Software Development> 中提到的，加强build工程的频率会更好的减少以后调试错误的时间，此外，也可以起到督促组员工作的功能。
4.任务分配更加平均：这次的任务其实有明显的不平均的情况，导致有的组员做了很多工作，有的组员做的就稍稍少了一点，之后的任务分配会更加的公平，旨在发挥每个组员的最大潜能。
三、资源
3.1 我们有足够的资源来完成各项任务么?
一个由7名同学组成的团队，资源很难做到全面充足。但总体来说，我们的工作进度并没有受到资源的限制。
人力资源方面，我们Z-XML团队应该是人力资源最为丰富的组了，这一点非常难得。全队共有7名队员，每个人都做事高效认真，其中至少4名同学具有极强的编程能力，2名同学具有丰富的游戏经验，2名同学具有丰富的学生工作经验，2名同学会使用PS等美术设计工具……以开发一个有趣的游戏为团队目标来说，从团队分工和个人工作量等角度来考虑，我们的人力资源是合理而全面的。
软件资源方面，在互联网高度发达的时代，软件资源的获取并不费力。本组开发的游戏《BlueZ》以cocos-2dx为开发引擎，该引擎已经得到广泛的应用，相关的软件资料已经非常丰富；另一方面，我们在VS2012上进行开发，微软的IDE已经相当成熟。因此，软件资源是非常丰富且容易获取的。
硬件资源方面，《BlueZ》主要在应用Android操作系统的移动设备上运行，因此我们除了需要开发用的个人PC外，还需要一些Android移动设备，比如手机。在“人人有手机”且“安卓遍天下”的时代，这些设备相当容易获取。因此，我们的硬件资源并不匮乏。
美术资源是需要单独说明的一个方面，因为一款游戏的精美程度很大程度上取决于美术资源的精致与否。相较其他资源，美术资源是最为匮乏的。一方面我们的团队没有自主设计创造优质美术资源的能力，另一方面，互联网上高质量且免费的美术资源相对较少，我们只能从几个相关的网站上获取有限的资源。总之，我们只能对互联网上获得免费的美术资源进行选择和加工，不能自主创造，美术资源较为匮乏。
3.2 各项任务所需的时间和其他资源是如何估计的，精度如何?
首先，在估计任务所需的时间之前，我们会对每项任务进行细化与分工，使每个任务相对独立且易于分配。然后我们会将所有任务在尊重队员选择的前提下平均分配，使得每个人分得的任务都是他擅长/愿意做的。
比如，在对游戏开发的工程进行模块的划分的时候，考虑到肖俊鹏在算法方面比较擅长，所以就分配给了他AI的工作；毛宇对引擎比较熟悉，就让他完成了游戏的主逻辑模块。
在此之后，我们才会估计任务所需的时间和资源——这件事由任务的负责人来完成。因为每个人对自己的任务相对了解/感兴趣，因此他能够得出一个合理的估计。
最后，全队会对每个人的任务进行一个审核，以确保每个人对任务的估计是合理的。
在这样的估计流程之后，可以看出我们对任务所需的时间和资源的估计精度较高，也证明这种流程是较为合理的。
在总体的估计比较高的情况下，也有一些没有做好的情况——由于我们组大部分人都没有cocos2d-x的开发经验，有时候分配的内容会有些失衡。比如我们错误估计了地图模块的工作量，认为会非常花时间，于是把它交给了编程大牛薛神，结果最后我们发现地图的模块是比较简单的，让薛亚杰来处理这部分有点浪费资源了。
3.3 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
正如前文所说，队伍成员人数较多，能力较强，团队执行力强，软硬件资源不受限制。因此，总体上测试的时间，人力和软硬件资源都较为充足。特别是由于我们组开始项目都早早优先于其他组，所以时间非常充足，甚至留出了两天的缓冲时间。
由于我们对任务的划分较为合理，甚至寻找某个方面的美术资源也会成为一项特殊的任务，再加上我们对任务的耗时、耗资预估较为合理，所以我们没有低估获取那些不需要编程的美术资源的难度。对文案的撰写，我们知道不能像其他组那样留在最后来赶工，所以一直坚持，一边开发，一边写文档的工作习惯，结果是非常高效的。
3.4 你有没有感到你做的事情可以让别人来做（更有效率）?
正如上文所说，我们的任务分配是尊重每个队员的选择的，一定是每个队员较为擅长/感兴趣的。因此大家各司其职，不会感觉到自己的任务让他人来做会是更好的选择。
但是从效率的角度上来说，我们依然有很多可以改进的地方，比如，如果让薛神来参与游戏的主逻辑，或者配合肖俊鹏共同完成敌军的AI模块，而把地图模块的编写交给编程能力稍稍弱一点的同学，整体的效率将会被提高。
3.5有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在游戏最初的开发阶段，我们认为对美术资源的要求可以降低一些，因此第一个版本完成时，大多数美术资源的质量都较低。当第二次修改美术资源时，我们发现当时在美术资源方面的付出不够合理：
第一，我们没有意识到，即使是找一些质量不高的美术资源，也是需要耗时耗力的。我们花了时间去寻找一些质量不够高的美术资源，而这些资源却不能用到最后。这是对人力和时间的一种浪费。
第二，我们没有意识到，有些美术资源是需要一次性做好的。这些美术资源影响了游戏的整体设计以及某些功能的实现。因此我们需要在最开始就制作好这些资源的最终版。
所以我们应该改进的是，在那些不重要、可以下次改进的美术资源上应该尽可能地少花时间，不做无用功；在那些重要的美术资源上应该花更多的时间，保证开发顺利进行。
四、变更管理
4.1 每个相关的员工都及时知道了变更的消息?
是的。Z-XML团队中的6名男生都住在同一楼层，互相见面沟通非常方便，PM可以选择互联网、短信、电话、面谈等多种方式与相关员工通知变更消息，确保消息通知及时。至于通知女生，PM一般先在QQ群上发布变更消息，如果员工没有回应，PM会发短信或打电话，确保变更消息通知及时。
4.2 我们采用了什么办法决定“推迟”和“必须实现”的功能?
无论是例会还是紧急会议，我们只在会议上做出决定。
首先，我们会对每个需要决定的功能进行集体讨论，大家各抒己见，在不断地剖析问题之后得出该功能实现的必要性。接下来，负责实现该功能的组员会根据自身情况分析实现该功能的难度。最终，团队将功能实现的必要性和难度综合考虑，决定“推迟”还是“必须实现”。
4.3 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
对于主界面、地图、敌军AI、技能等模块，有较为清晰的出口条件定义。而整个项目以及某些没有经验的模块的出口条件，仅有比较宽泛的定义，如bug较少、可玩性较高、视觉效果较好等等。
当然，在实现的过程中，出口条件还会不断的修改或确立。不过大家共同的出口条件都是尽我们所能做出最好的团队游戏。
4.4 对于可能的变更是否能制定应急计划?
团队的PM通常能够整合全队资源，针对变更制定应急计划。例如，如果有组员不能够及时完成自己的任务，PM会安排此段时间较为空闲的组员代为完成，保证项目的及时、顺利完成。
4.5 员工是否能够有效地处理意料之外的工作请求？
员工一般能够有效处理意料之外的工作请求，但完成质量比较容易受到当时的环境影响。接到工作请求时，如果员工时间充裕，则会努力将其做到最好；如果和员工个人计划相冲突，则可能仅完成工作的基本要求。
4.6我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们认识到了和个人项目不同的团队协作的重要性。在一般的个人项目中，计划的变更只要是自己协调好了就可以，如果遇到时间实在太紧，可以熬夜进行完成；但这在团队中是几乎不可能的，任何任务的拖延都会影响到其他组员的时间计划安排，所以应该尽力在规定的时间完成自己的部分，即使实在有困难，也必须要咨询其他组员，是否可以适应你的变更，始终要从团队的利益出发考虑问题。
如果历史重来一遍，我们希望将计划的出口条件设定的更加明确一些，这样每个组员就可以以更高效的方式完成自己的部分，不需要进行反复地修改。但这作为项目经验较少的学生来说，有一定的困难，因为无法非常准确地进行结果的预估，而且也可能会一定程度上影响项目的灵活性。所以，希望通过团队的讨论找到一种较好的方法，使得每个人的部分可以很好地与全队项目相融合，做到“形散神聚”。
5 设计/实现
5.1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是大家一起完成的。每个部分的设计详情可以参考我们小组10月22的会议记录。应该说项目一拿到第一时间就是完成设计工作，而且每个模块的设计人员都是对那个模块很感兴趣，最后的设计都是很有意思的。
5.2 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
项目中有些模块的设计确实碰到过模棱两可的情况，比如说主角的攻击方式的设计，一开始是设想点击屏幕来选择位置或者有根据当前方向攻击，这个问题其实在开发结束前都还没有完全确定下来。最后是小组成员觉得目前版本的攻击方式挺不错的，才决定下来了。
5.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
单元测试很遗憾没成功。由于测试人员对于C++的单元测试功能不熟悉以及开发时间所限，没有做单元测试。在开发的过程中我们用到了UML图展现各个模块以及借口，这样让全体开发人员对于彼此间模块的关联都了解了一下，能大幅提升开发效率。
5.4 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
在开发过程中，敌军产生的bug是最多的，很大程度上是因为敌军类整体的难度是最高的，设计到AI设计，还要和主角和地图顺利交互，这本身就很可能带来大量的bug。在发布后暂时没有发现什么重大的bug。
没有在设计/开发时想到这些情况的主要原因在于第一次这么多人一起合作写代码，工程量比较大，大家的经验不是非常的丰富，不能进行很好地判断。但这也让我们积累经验，以更好地进行下一轮开发。
5.5 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
首先每个模块写完，负责的同学都会进行一次自我的代码复审。然后代码汇总后，由负责整合游戏的毛宇同学再一次进行复审。
我们并没有一个严格的代码规范，但是我们简要地说明了一些规则来保证代码的可阅读性，例如，变量名尽量起得比较有意义，要进行比较合适的注释，再提交自己部分的代码时要附上自己的测试代码等。
5.6我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
最初设计的时候并没有很完整把整个框架都设计出来，这也导致了开发过程进行到了一半时各个模块的工作进度没有协调好。接口没有设计好，导致一些功能实现的难度增大。更重要的是，此次项目没有成功完成单元测试，这其实也有最初接口没有设计好的原因。如果重来一遍，我们在最初的设计中一定更加严格的遵守软件工程的要求。
6测试/发布
6.1 团队是否有一个测试计划？为什么没有？
没有一个十分完整的测试计划。第一轮迭代时间紧任务重，又因为大家都是第一次进行软件工程开发，经验欠缺，无法一开始就制定明确的测试计划。
6.2是否进行了正式的验收测试？
进行了最后的验收测试。而且事实上在最后一周全团队都在进行测试。
6.3 团队是否有测试工具来帮助测试？
这次迭代的测试基本上由手工实现。最开始尝试使用VS自带的单元测试工具，但是结果发现与游戏引擎自身有冲突。在第二次迭代时将尽量寻找可用的测试工具帮助测试。
6.4 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
软件实际运行时，在加载的时候没有预想的那么流畅，但是在加载之后不会出现卡顿的现象。没有发现跟踪软件效能的工具，主要还是凭借人工的操作和体验。因此，下一次迭代在这方面要做些功夫。
6.5 在发布的过程中发现了哪些意外问题？
Android市场审核的时间超过我们的预计，以至于较晚才通过审核，给出下载链接。
6.6我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
软件的测试十分重要。如果少做测试或者不做测试，那么后期会花很大功夫在调试上。这点上我们确实也努力做了测试。但是未能使用一些专门的工具进行测试，这一点是不足的。而且设定一个测试计划应该能使整个测试过程显得更有安排、更不容易缺漏。对于软件效能，我们也会在后续的过程中寻找相关的测试工具帮助测量。
7.总结
7.1你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我们团队在第一次迭代的开始时间里基本处于CMM/CMMI中的第二级：可重复级。但是经过后期的程序、文档规范化过程之后，正向第三级：已定义级过渡。首先，我们在开始创建项目的时候，就基于类似项目中的经验，建立了基本的项目管理制度，采取了一定的措施控制费用和时间。管理人员可及时发现问题，采取措施。一定程度上可重复类似项目的软件开发。
在第一次迭代中后期，团队一直在规范化各个方面，目前已经已将软件过程文档化、标准化，可按需要改进开发过程，采用评审方法保证软件质量。但是仍然没有借助CASE工具提高质量和效率。所以说团队正处于第二状态与第三状态的过渡期。
7.2你觉得团队目前处于 萌芽/磨合/规范/创造阶段的哪一个阶段?
正如CMM/CMMI中我们正处于第二阶段到第三阶段的过渡状态，目前团队正处于磨合到规范的过渡状态。在前四周的工作之中，我们团队相互磨合，已经较为成功的完成了整个项目的第一次迭代。并且在这之上我们定义了相关的文档，已经将程序部分规范化。大家协同作战，成员们就很多事情取得了一致。角色和职责定义得非常清楚。团队还进行过有趣的团队建设活动。
但正如他人经验之谈，并不是当团队进入到了规范阶段，就万事大吉了。经验表明，很多情况下团队会由规范阶段回到磨合阶段，或者在两个阶段间徘徊。团队成员们必须努力工作，才能使团队保持在这一阶段, 他们同时还要抵御外界的压力，以免使团队分裂，或者回到磨合阶段。所以我们团队目前正处于两个阶段的过渡阶段。
7.3你觉得团队在这个里程碑相比前一个里程碑有什么改进?
本次发布是我们的第一个milestone。因此没有前一个里程碑可比。但是大家从一开始没有什么基础到现在已经发布出来一个成果，我们认为整个团队的进步是显而易见的。在四个周的时间内，团队完成了萌芽阶段、磨合阶段，正向规范阶段过渡。这个效率也是很高的。
7.4你觉得目前最需要改进的一个方面是什么?
软件工程还剩4周的迭代时间。我们仍然处于一个过渡阶段，也就是虽然大部分的规范规则已经定义，但是仍然有不少东西还处于未定义、未规范化的状态。在7个人的小组开发内这个不会出现什么问题，但是这样子的成果可维护性、可移植性不是很高。所以我们下一步会更加的规范这一类的程序、文档。争取在第二次迭代中期进入CMM中第三阶段，使团队状态处于规范阶段。
7.5 对比敏捷的原则, 你觉得你们小组做得最好的是什么?
对比敏捷的原则，我们组做得最好的就是daily scrum了。在两周的实现周期里，我们基本上每天一面，总结前一天的完成量，计划第二天的任务，而且这些变化都记录在tfs中。这也是我们在进度上紧跟时间安排的原因之一。
7.6 什么是在下个阶段 M2 要改进的地方? 越具体越好。
这个阶段的不足，以及下个阶段要改进的地方，已经都在上文中列出了。主要的问题如下：
1、正式开发前没有完全定义好接口，使得整合工作难度加大。主要原因在于本身这是一件比较难的事情，而在最开始团队中大多数成员基本没有游戏开发的经验，因此最后由一两个人定义出来的接口较为粗糙。经过第一次迭代之后，所有人都熟悉了这个引擎和游戏开发，因此这个问题在M2阶段将很容易解决。
2、分工上没有完全利用好团队资源。也是由于经验不足，我们在分工的时候确实对某些模块的工作量和难度有误判，使得能力较强的同学反而没有发挥的空间。同样由于第一次迭代的经验，这个问题也将不会在M2出现。而对于美工的事情，因为大家都是计算机系的同学，也为了每个人都得到锻炼，所以在最开始没有专门的同学负责美工。在第二次迭代时，我们将会安排专人负责该项工作。
3、对软件的测试和效能测量，没有使用专门的工具进行。下一阶段将寻找相应的方法专业化我们的测试。
最后，愿我们Z-XML在第二轮迭代中，发扬优点，改正缺点，共同进步，友谊长青！
