设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
要做一个游戏，定义的很清楚，实现出来的效果贴近定义，对用户和场景有清晰描述
- 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
原计划目标提早实现，还多做一些额外的功能
- 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
提高了，在代码管理和代码测试方面，具体来说规范了commit和实现了代码覆盖率测试
- 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
基本一致，增加了详细的新手引导，优化了用户体验，离目标更近了
- 有什么经验教训? 如果历史重来一遍,我们会做什么改进?
吸取了上次的教训，我们这次的设想与目标较为接近，基本不需要改进
计划
- 是否有充足的时间来做计划?
很充足
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
开会讨论，然后投票
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
计划的都提前做完了，还做了很多额外的工作
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
有一些，比如UI的改进完成后发现没原来的效果好又换回去了
- 是否每一项任务都有清楚定义和衡量的交付条件?
有大致的交付条件，跑起来大家觉得没问题就行
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
基本按计划进行，意外时策划换人了，但是属于估计内
- 在计划中有没有留下缓冲区，缓冲区有作用么?
有，拿缓冲区做了额外的内容
- 我们学到了什么? 如果历史重来一遍,我们会做什么改进?
组员们的工作效率有点高，下次会做更多的计划
资源
- 我们有足够的资源来完成各项任务么?
基本足够，在3D建模方面没有相关人才，只能找免费资源
- 各项任务所需的时间和其他资源是如何估计的，精度如何?
由PM和负责人沟通来估计时间，精度还不错
- 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试方面比较足够。没有低估难度，但建模资源确实不够，总是做不出想要的效果
- 你有没有感到你做的事情可以让别人来做（更有效率）?
没有
- 有什么经验教训? 如果历史重来一遍,我们会做什么改进?
找一个会建模的男生
变更管理
- 每个相关的员工都及时知道了变更的消息?
知道，因为每天开会
- 我们采用了什么办法决定“推迟”和“必须实现”的功能?
一开始定下需要完成的基本任务，以基本任务优先
- 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
定义的比上次清晰，我们达到了我们定义的做好了的标准
- 对于可能的变更是否能制定应急计划?
没有提前制定计划，有机动人员负责应急
- 员工是否能够有效地处理意料之外的工作请求？
能
- 我们学到了什么? 如果历史重来一遍,我们会做什么改进?
这次做的比上次好，基本不会有改进
设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在开发还没开始的时候，由主策划和其他策划完成，是合适的时间合适的人
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有，因为模棱两可的上次都解决了
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
有用画图工具（sketchbook、ps、ai）帮助设计。设计文档有小改进，考虑了更多的细节
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
屏幕适配功能问题较多，发布后发现不同机型会出现一些特殊的bug，光线渲染表现也不一样。因为没有经验，没考虑这么多
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审没有进行，代码规范比较严格
- 我们学到了什么? 如果历史重来一遍,我们会做什么改进?
写代码前要考虑不同平台的适应问题，不要进行这么多修修补补
测试/发布
- 团队是否有一个测试计划？为什么没有？
有测试计划，边写边测。最后发布后有一个机型测试
- 是否进行了正式的验收测试？
是
- 团队是否有测试工具来帮助测试？
unity自带的testrunner工具，CodeCoverage插件
- 在发布的过程中发现了哪些意外问题？
吸取了上次的教训，这次在发布上没碰到严重的问题，主要是不同手机的自适应问题
- 我们学到了什么? 如果历史重来一遍,我们会做什么改进?
会中途就测试不同的手机
团队的角色，管理，合作
- 团队的每个角色是如何确定的，是不是人尽其才？
角色是自主报名+PM调配，是
- 团队成员之间有互相帮助么？
有，帮的还蛮多的
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
频繁沟通，避免冲突出现；如果冲突出现则交流解决；减少每次commit的工作量，频繁commit
-
公开感谢
黄贤昊 我要感谢何瑞帮助我处理了技术博客的问题
何瑞 我要感谢吴昭邦和马嘉帮我完成了Unity测试部分的工作
朱俊豪 我感谢吴桐雨对我的帮助，因为：具体设计了部分界面UI；
我感谢何瑞对我的帮助，因为：协助调整了场景光源；
我感谢马嘉对我的帮助，因为：优化了合成效果(齿轮）；
我感谢黄贤昊、何瑞对我的帮助，因为：提供了部分游戏背景音乐。梁河览 我感谢吴桐雨对我的帮助，因为在Beta阶段她和我一起做新手引导，当时互相帮做工作。
吴昭邦 我感谢马嘉对我的帮助，因为他帮助我更换了齿轮模型。
吴桐雨 我感谢朱俊豪、梁河览、黄贤昊对我的帮助，因为前两位同学在我不会导入素材走投无路的时候非常热心地帮我解决问题，后一位同学在我不会设计关卡走投无路的时候非常热心地为我指明方向。
马嘉 我感谢梁河览对我的帮助，因为他帮我接手了新手引导部分的工作。
总结
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
管理级
- 你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?
心态到了创造阶段，但是技术和能力没到（主要在建模方面）
- 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
有了美术同学，美术方面有很大改进，还有新手引导和用户体验。会在开发中导出中间版本，即时根据反馈修改计划
- 你觉得目前最需要改进的一个方面是什么?
游戏的难度曲线存在一些问题，最后几关相比之前较为简单
-
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
-
尽早并持续地交付有价值的软件以满足顾客需求
在Beta阶段开发中有持续导出中间版本并收集和回应反馈
-
经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
Beta阶段基本一周发布一个版本
-
无论团队内外，面对面的交流始终是最有效的沟通方式
虽然由于疫情原因无法见面，但我们几乎每天通过腾讯会议沟通
-
可用的软件是衡量项目进展的主要指标
我们组衡量一个工作是否完成的主要方法就是看这个功能在实际软件中的效果
-
只有不断关注技术和设计，才能越来越敏捷
游戏方面经常出现需要学习的新内容，例如新手引导时的gif视频导入，我们团队一直在学习新的技术
-
保持简明——尽可能简化工作量的技艺——极为重要
Beta阶段简化了成本和分数系统，让其简单易懂。简化了合成指南，去除了其中冗余的信息
-
以有进取心的人为项目核心，充分支持信任他们
程序总能提前完成任务，鼓舞团队士气，PM也常常提出指团队前进方向，合理的分配最适合的人完成任务
-
团队在下一阶段应该如何提高软件工程的质量
- 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
代码管理没有太大问题，没有提高需求
- 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
写之前思考架构，尽量避免重构
- 其它软件工具的应用，应该如何提高？
unity功能强大，本身支持很多插件
- 项目管理有哪些具体的提高？
任务粒度分的更细，提前准备任务提前完成后的后续任务
- 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
由发布平台的反馈，由于是单机游戏所以没有活跃用户，计划提高用户反馈，在游戏内提供反馈接口
- 项目文档的质量如何提高？
目前质量挺好的
- 对于人的领导和管理， 有什么具体可以改进的地方？
绩效考核上对任务工作时间有更细的评判
- 对于软件工程的理论，规律有什么心得体会或不同意见？
| 成员 | 心得与体会 |
|---|---|
| 何瑞 | β阶段的收获就是深刻地感受到设计阶段的重要性。在游戏的设计之初，我们其实并未明确的定义各个关卡中哪些组件是可重用的，形成一个技术文档，因此开发后各个关卡中冗余的prefab比较多，后期调整各个关卡都有的组件时发现要对每一关都做调整，而不是只用改一个prefab，这非常不简洁。其次就是加深了对Unity的了解，结合官网手册和百度解决了不少开发中的实际问题。 |
| 马嘉 | 我在beta阶段，更加深刻地了解了软件工程项目的理论，了解了软件工程项目中各个角色的定位和职责。还有就是体会到了软件工程项目中，成员之间的沟通很重要，沟通能提高效率。 |
| 吴昭邦 | 技术方面。主要学习了如何利用unity实现简单游戏功能，还学习了unity里的动画控制和坐标关系等知识 团队方面。锻炼了团队交流和团队协作的能力，作为一个大的项目，团队成员之间的合作非常重要，因为一个环节的完成情况会影响到其他的环节，所以大家都会互帮互助，争取尽早尽好地完成任务。而且和一个团队的成员在一起工作还会各自学习到他人解决问题的方法，他人思考问题的方式。大家通力合作，最后可以说是完美地完成了这个软工项目，这个过程用到的所有方法所有交流都是宝贵的经验。 |
| 黄贤昊 | 在Beta阶段，作为一个PM主要学到的东西是如何为团队介绍一个新成员，包括对新成员的上手引导和工作安排，这些工作都是以前没有预想过的。另一方面，在软件开发上，我认识到了中间版本的重要性，通过发布中间版本，可以即时发现一些bug和设计上的问题，即时调整开发内容和方向 |
| 梁河览 | 在Beta阶段学了很多东西。更了解怎么合理分工，然后有问题的话队员之间讨论解决问题，互相帮助工作。学了unity上的很多功能。 现在我感觉我的unity能力进步很大。 |
| 吴桐雨 | 经过Beta阶段的学习，敏捷开发的思想已经直击我的灵魂深处，密集的会议与交流帮助我快速熟悉了工作，频繁交付新版本能帮助大家不断审视过去的工作从而进行改进。然而，由于前期的爆肝，我的身心已经不堪重负了。我建议在个人项目与结对项目期间能少些博客作业，让下届小同学能有一颗健康的肝脏。 |
| 朱俊豪 | 回顾整个课程，我们学习到了一些软件工程的理论知识，并且以实践体会学习，我们团队做了一款具有教育意义的编程启蒙游戏。在团队开发的过程中，采用“敏捷开发”的方式，以需求为目标，与队友的讨论合作令人进步。对该课程而言，学习到软件工程知识是较重要的。课程组应以更具体的方式考察各组对软件工程知识的实践。 |
事后总结会议截图
