[对对子队]事后总结

设想和目标

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

要做一个游戏，定义的很清楚，但是实现出来的效果和定义的还是有差距

我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)

基本目标到达了，但是效果不理想

用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

并不一致，发布Alpha版本时没注重引导，对用户造成了困惑

有什么经验教训? 如果历史重来一遍,我们会做什么改进?

我们会注重新手引导，可能会先做引导再做功能；先调研再制作，更多的站在用户角度考虑

计划

是否有充足的时间来做计划?

很充足

团队在计划阶段是如何解决同事们对于计划的不同意见的？

开会讨论，然后投票

你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

计划的都做完了，但出现了计划外的事并没做完，所幸都是些小问题

有没有发现你做了一些事后看来没必要或没多大价值的事?

有不少，开始菜单的一些按钮功能后来其实没有用到，合成指南的功能后来也简化了

是否每一项任务都有清楚定义和衡量的交付件?

不是很清楚，跑起来大家觉得没问题就行

是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

基本按计划进行，意外是有组员病倒了，他留下的功能继续接手起来很麻烦；发布的时候平台要求超出我们预料，但是由于预留了缓冲区所以没出大问题

在计划中有没有留下缓冲区，缓冲区有作用么?

有，在发布时候起了很大的作用

我们学到了什么? 如果历史重来一遍,我们会做什么改进?

计划赶不上变化，要多留一些缓冲区，这次发布没出大问题就是因为留了缓冲区

资源

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

技术不够，主要是美术方面，只能找免费资源东拼西凑，工科生审美不够

各项任务所需的时间和其他资源是如何估计的，精度如何?

由PM和负责人沟通来估计时间，精度还不错

测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

测试方面比较足够。没有低估难度，但美工资源确实不够，总是做不出想要的效果

你有没有感到你做的事情可以让别人来做（更有效率）?

没有

有什么经验教训? 如果历史重来一遍,我们会做什么改进?

我们会找一个会美术的女生

变更管理

每个相关的员工都及时知道了变更的消息?

知道，因为每天开会

我们采用了什么办法决定“推迟”和“必须实现”的功能?

一开始定下需要完成的基本任务，以基本任务优先

项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

没有很清晰定义，能玩就行，没太考虑什么叫做好了

对于可能的变更是否能制定应急计划?

没有提前制定计划，有机动人员负责应急

员工是否能够有效地处理意料之外的工作请求？

能

我们学到了什么? 如果历史重来一遍,我们会做什么改进?

会去了解更多相关产品来明确什么叫做好了

设计/实现

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

在开发还没开始的时候，由主策划和其他策划完成，是合适的时间合适的人

设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有，投票

团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

有用画图工具（xiaopiu）帮助设计。设计文档有小改进，考虑了更多的细节

什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

屏幕适配功能问题较多，发布后发现不同机型会出现一些特殊的bug。因为没有经验，没考虑这么多

代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

代码复审没有进行，代码规范比较简单但是执行了

我们学到了什么? 如果历史重来一遍,我们会做什么改进?

写代码前要考虑周全，不要进行这么多修修补补

测试/发布

团队是否有一个测试计划？为什么没有？

有测试计划，边写边测。最后发布后有一个机型测试

是否进行了正式的验收测试？

是

团队是否有测试工具来帮助测试？

unity自带的testrunner工具

在发布的过程中发现了哪些意外问题？

很多情况，发布需要很多证明，比如版权证明和游戏版号，无法过审核。手机的适配问题。gif无法在安卓上正确显示等

我们学到了什么? 如果历史重来一遍,我们会做什么改进?

会中途就考虑跨平台会出现的问题，先导出一个安卓版本

团队的角色，管理，合作

团队的每个角色是如何确定的，是不是人尽其才？

角色是自主报名+PM调配，是

团队成员之间有互相帮助么？

有，帮的还蛮多的

当出现项目管理、合作方面的问题时，团队成员如何解决问题？

频繁沟通，避免冲突出现；如果冲突出现则交流解决；减少每次commit的工作量，频繁commit

公开感谢

黄贤昊 我要感谢何瑞帮助我寻找一个可以发布我们游戏的应用平台

何瑞我要感谢马嘉帮我解决Unity下拉框的技术问题，感谢吴昭邦帮我解决了Unity play mode模式下的测试问题。

朱俊豪 我感谢何瑞对我在界面UI设计上提供了素材与帮助，感谢黄贤昊在场景搭建上提供了素材与思路，感谢马嘉帮忙寻找了部分3D模型素材。

梁河览 我感谢吴昭邦对我的帮助，因为我不知道的时候问吴昭邦。他认真回答我的问题。这件事不是一次。所以我感谢他。

吴昭邦 我感谢何瑞对我的帮助，因为他帮助我修改了合成顺序判断的逻辑。

刘子航

总结

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

管理级

你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?

规范阶段，在向创造阶段迈进

你觉得目前最需要改进的一个方面是什么?

测试与开发同步进行，提高组员审美

对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 无论团队内外，面对面的交流始终是最有效的沟通方式
  
  虽然由于疫情原因无法见面，但我们几乎每天通过腾讯会议沟通
- 可用的软件是衡量项目进展的主要指标
  
  我们组衡量一个工作是否完成的主要方法就是看这个功能在实际软件中的效果
- 只有不断关注技术和设计，才能越来越敏捷
  
  游戏方面经常出现需要学习的新内容，例如新手引导时的gif视频导入，我们团队一直在学习新的技术
- 保持简明——尽可能简化工作量的技艺——极为重要
  
  新手引导的显示我们一开始计划不直接显示，而是一直有一个按钮可以呼出，后删减为进入第一关是自动显示，将第一关与新手引导绑定，简化工作与设计。
- 以有进取心的人为项目核心，充分支持信任他们
  
  程序总能提前完成任务，鼓舞团队士气，PM也常常提出指团队前进方向，合理的分配最适合的人完成任务

团队在下一阶段应该如何提高软件工程的质量

代码管理的质量具体应该如何提高？代码复审和代码规范的质量应该如何提高？

代码管理没有太大问题，没有提高需求

整个程序的架构如何具体提高？如何通过重构等方法提高质量，如何衡量质量的提高？

写之前思考架构，尽量避免重构

其它软件工具的应用，应该如何提高？

unity功能强大，本身支持很多插件

项目管理有哪些具体的提高？

任务粒度分的更细

项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

由发布平台的反馈，由于是单机游戏所以没有活跃用户，计划提高用户反馈，在游戏内提供反馈接口

项目文档的质量如何提高？

目前质量挺好的

对于人的领导和管理，有什么具体可以改进的地方？

绩效考核上对任务工作时间有更细的评判

对于软件工程的理论，规律有什么心得体会或不同意见？

成员	心得与意见
何瑞	α阶段最大的收获就是get了使用Unity开发游戏的新技能了吧，此前我对Unity的了解几乎为0，经过几周的开发，对如何制作游戏了解更加直观深入，其次是丰富了团队合作开发经验。课程组也是比较nice的，暂时没有改进建议
黄贤昊	Alpha阶段的收获大概就是学习了作为一个PM应当怎么管理一个团队，之前虽然有做过敏捷开发但是并没有负责过PM的职位，这次的软件工程给了我这么一个机会。对课程的建议是希望提供一个app发布的平台，现在国内对app发布的管控越来越严了，需要很多相关证明和文件才能发布
朱俊豪	经过alpha阶段的实践，对软件工程的项目团队开发工作有了深入的了解。一方面与团队交流、工作交接交互等方面有锻炼，另一方面在其他队友的代码风格能力或者工作方法有取长补短。另外，每次课程上老师对我们团队或者其他团队提的建议或意见都很有力度，有所帮助。
梁河览	在Alpha阶段学了很多东西。比如说怎么合理分工，然后有问题的话相互讨论解决问题，协作完成工作，unity等等。
吴昭邦	技术方面。主要学习了如何利用unity实现简单游戏功能。团队方面。首先，在做较大项目时，将任务进行分解并分配到对应的角色是很重要的，这会让人明确自己的工作目标，从而提高效率。其次，作为负责程序编写的成员，明白了开发和测试是不能完全割裂开的。在进行一项开发任务之前，应该提前编写好对应的尽量完备的测试程序。
刘子航	作为一个策划，在Alpha阶段，我学会了对市面上类似的游戏的作出更加公正专业的评价方法，尝试了给团队制定代码规范，尝试了用设计工具、绘画等方法将自己对游戏的构思设计形象的描述出来；对于课程，我希望能够少一些文字作业，作业要求中少一些不必要的问题需要回答（其中有很多关于问题可以简化），取而代之的是更多的规范编码教程、设计流程和管理技巧等。另一方面我也更希望助教能够学习一些关于所选项目的知识或者根据项目选择跟队助教，让助教也能参与到的团队的建设当中，而不是单纯的发作业改作业、在组内会议中挂机。