Alpha事后诸葛亮

队名：new game

组长博客

作业博客

Alpha阶段总结（现代软件工程 项目Postmortem 模板）

一、设想和目标（2分）

我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

我们的软件是一款音乐游戏，是一款面向休闲的游戏娱乐软件，典型用户即为对音乐游戏感兴趣的游戏玩家，典型场景即普遍的娱乐场景。

我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
到达了预期的目标。考虑到游戏的复杂性和人员的开发经验和开发时间安排，我们对alpha阶段的目标是学习为主实现为辅，力求高质量实现项目目标。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
暂时没有考虑用户对软件功能的调查。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
统一原型是一件非常重要的事情，如果历史重来为会选择由少数人统一设计项目原型，否则会导致不同部门的项目风格天差地别。

二、计划（5分）

是否有充足的时间来做计划?
计划的时间很多但个人认为还远远不够。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
我很清楚自己的想法并不是大家的想法，因此对于不同的意见都会进行讨论，并想办法一起改善不好的想法，或是完全抛弃。多数情况下遵从少数服从多数原则。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
其实没有完全完成，最主要的原因还是学习的不够深度。
有没有发现你做了一些事后看来没必要或没多大价值的事?
想了想，应该没有，想到的话再补充。
是否每一项任务都有清楚定义和衡量的交付件?
没有，甚至很多任务都没有定义交付内容。Alpha的重点是学习，因此我给予队友非常大的自由，直到Beta阶段再以目标约束。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
意外很多。我们组非常巧的是一整个组有一半的人参加了今年的ICPC赛事，几乎每一周都有人离开学校奔赴各个赛场，或是经常进行相关赛事，难以找到一个统一的时间开发项目
在计划中有没有留下缓冲区，缓冲区有作用么?
有，制定目标时以学习进度预留了项目目标完成评定，很多任务有“尽可能完成”目标。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
缩小缓冲区，直到取消。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
更加详细和明确一下计划目标吧，过于自由很容易导致成员实施计划时没有一个明确的方向。

三、资源（3分）

我们有足够的资源来完成各项任务么?

资源还是很少的。

• 首先大多数成员没有开发经验，在学习Unity和C#的过程中缺少中文的学习资料，学习难度很大；
• 第二，项目的网络功能需要具体的生产环境，这是项目的开销之一；
• 接着对于游戏来说，素材的数量和质量都是非常重要且占比极大的资源，但我们组的成员都不会绘画，只能依靠外包来解决项目资源。
  不过对于Alpha阶段，学习资料是任务完成比较重要的资源，美术素材计划Beta版再上线。

各项任务所需的时间和其他资源是如何估计的，精度如何?
目测。经验不足没有进度非常高的资源估计方法。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
Alpha阶段的测试暂时由开发人员自行测试。对于不需要编程的资源自项目开始便认为难度很大，但现在来看当时的预估还是低估了不少。
你有没有感到你做的事情可以让别人来做（更有效率）?
可能有，但组长是我。。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
学习资料要提前做好更充分的准备，并及时与组员交流。

四、变更管理（4分）

每个相关的员工都及时知道了变更的消息?
大概，对于事项变更都有及时的在群内艾特或是发出公告。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
以难度和学习进度划分。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
符合人物制定之初设定的期望即可
对于可能的变更是否能制定应急计划?
有，加大人手并亲自赶工。
员工是否能够有效地处理意料之外的工作请求？
可以，对于意料之外的任务在DDL之时都有很好的完成目标。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
计划制定需要有长远的目光，以减少不必要的紧急计划。

五、设计/实现（4分）

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
我们的小组由任务分块的不同分成了四个不同的部门，并有专门的负责人，在Alpha设计阶段每位负责人负责安排设计各自部门的工作。
分组计划在Alpha阶段开启前便开始执行了。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
模凌两可即为自由发挥，对于没有提到的情况可以询问队友或是自己解决
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
下发任务时有要求各部门在上交成果前进行功能测试，并编写使用文档和测试报告。
比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
没有区别，一切都在按计划进行。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
在Alpha阶段，代码复审由各部门的负责人进行，要求严格执行项目开始时规定的设计文档。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
Alpha阶段的目标和成果都更接近底层，很难有可以呈现给使用者的部分，如果重来的话估计会更合理的安排Alpha发布版本的可视部分。

六、测试/发布（3分）

团队是否有一个测试计划？为什么没有？
在Alpha阶段没有非常详细的测试计划，大多是进行模块的功能性测试。
是否进行了正式的验收测试？
还没有。
团队是否有测试工具来帮助测试？
Visual Studio。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
即使是Alpha阶段也需要进行详细的测试。

七、团队的角色，管理，合作（3分）

团队的每个角色是如何确定的，是不是人尽其才？
每个部分的分工主要由成员自己选择擅长的部分，没有强制分组。
团队成员之间有互相帮助么？
显然是有的，各部门之间都有交集的功能（例如周边部门与UI部门），因此各部门之间需要非常深的交流。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
自行商讨解决方案
每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
我感谢林得翔同学对我的帮助， 因为在为备战ICPC上海的过程中负责了Alpha冲刺博客的编写以及队长的一些职责。
我感谢钟博同学对我的帮助，作为UI部门的负责人，负责了UI的设计和安排，并且很好的实现了UI的设计。
我感谢罗继鸿同学对我的帮助，很好的实现了游戏的过程原型，为游戏关卡设计指明方向
我感谢陈志明同学对我的帮助，独自一人包揽了后端服务器的开发。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
合理的分工能让队伍成员各尽其能。

八、总结:（3分）

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
大概处于明确级吧。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
着手开始实现目标。
你觉得目前最需要改进的一个方面是什么?
对项目的投入力度。

答辩总结

贡献比例

组员	评分
鲍子涵	11
林得翔	10
钟博	12
吴宜航	7
黄海东	5
王镇隆	12
陈志明	14
罗继鸿	6
高鹏	7
刘俊杰	7
骆友鹏	9

答辩得分

组别	分数
第一组	52.2
第二组	52.2
第三组	44.2
第四组	54
第五组	49.8
第六组	49.2
第七组	52.2
第八组	47.6
第九组	52.2
第十组	49.2
第十一组	48
第十二组	35.4
平均分	49.68

问题回答

组别	问题	回答
第一组	音游节奏感如何体现？	打击节奏与音乐节奏重合产生共鸣
第二组	这游戏是像八方音符那种用声音的还是黑白块那种用手玩的	用手玩的。
第三组	这个音游音乐和游戏如何紧密结合？	音乐播放的过程中玩家操作人物通过关卡，就和舞步与音乐之结合
第五组	游戏过程和音乐是如何结合起来的	音乐播放的过程中玩家操作人物通过关卡，就和舞步与音乐之结合
第六组	这个游戏和音游的关系在哪里	跑酷体验是这个游戏的直接体现，音乐打击是这个游戏的本质
第七组	能否将音乐和游戏结合更加紧密？	会尝试优化，让音乐节奏点与对应操作的物品的重叠不出现误差
第八组	如何将背景音乐的节奏和游戏配合起来？	在节奏点上作出操作，操作与音乐节奏重合产生共鸣
第九组	对于部分音乐的版权问题如何解决	这个问题我上次回答过了。对于挑战模式，我们不会对其进行商业化，唯一收费的项目是用于维护用户社区的服务器，用户自己制作和上传的音乐素材不会被我们商业化使用，在版权方默许的非商业化环境下玩家可以随意上传、下载和游玩。具体方案会参考《OSU!》的处理方法。
第十组	这个游戏目前的实现是不是跟当初的想法有所偏离？	更具团队讨论后确实有不同的地方被改进，但是大方向上没有偏离
第十一组	击打跳跃滑铲三种动作怎么和音乐结合？	类似于各种舞蹈动作与音乐的结合吧
第十二组	你们这个游戏的核心玩法到底是什么？	滑块下落式音乐游戏，音乐游戏是本质，横版跳跃是表现形式

PSP表格

PSP2.1	Personal Software Process Stages	预估耗时 （分钟）	实际耗时 （分钟）
Planning	计划	30	24
· Estimate	· 估计这个任务需要多少时间	30	24
Development	开发	1510	1730
· Analysis	· 需求分析 (包括学习新技术)	600	780
· Design Spec	· 生成设计文档	30	20
· Design Review	· 设计复审	30	10
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	10	10
· Design	· 具体设计	60	40
· Coding	· 具体编码	360	300
· Code Review	· 代码复审	60	90
· Test	· 测试（自我测试，修改代码，提交修改）	360	480
Reporting	报告	90	90
· Test Repor	· 测试报告	30	30
· Size Measurement	· 计算工作量	30	30
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	30	30
	合计	1630	1844

学习进度条

第N周	新增代码（行）	累计代码（行）	本周学习耗时（小时）	累计学习耗时（小时）	重要成长
1	0	0	2	2	学习axure rp9的使用
2	0	0	4	6	学习http相关
2	400	400	10	16	学习java
3	0	0	3	19	学习swing
4	2000	2400	16	35	学习unity
5	2900	5300	10	45	学习C#