Alpha阶段项目Postmortem

以下对成员名字的简称：

陈鸿超 = 陈1
陈彦吉 = 陈2
石浩然 = 石
韩青长 = 韩

1. 设想和目标

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

我们的软件主要是用来解决玩狼人杀这款桌游时无牌、无法官、游戏流程不熟悉等情况的。我觉得我们对典型用户和典型场景描述的较为清楚，我们项目之前做了问卷调查，提出了一些功能，Alpha版本挑了用户较需要的几个功能重点实现，之后在Beta阶段我们将继续完善其余功能。

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

石：在开始之前，由于订立了比较激进前沿的技术栈选择方案，用了很长的时间在各种技术的学习熟悉上。在关于计划方面，虽然也很认真的做了规划，不过慢慢做下去发现可能跟最开始说好的不太一样。。。

韩：与后面开发阶段对比来说，时间相对充足。一周的时间大概够我们整理思路，进行NABCD分析，对软件开发做整体上的规划。

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

石：团队成员都很敬业和谐，基本上没有什么分歧，不过有时候因为其他科的繁重作业而对计划的执行有些拖延

陈2：辩论和妥协

韩：讨论解决。仔细分析问题的每个优缺点，大家共同商讨得出我们认为的最佳方案。如我们的项目最开始我是只想做一个Android客户端的，但石浩然同学坚持要做双平台——因为这样我们才能真正上线，才能真正拥有用户。最后权衡利弊，我们接受了他的想法。

1.4 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

因为Alpha阶段设立的目标就是发布内部测试版本。在克服了各种各样的困难之后。。。似乎没有时间发布给用户进行测试了。

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

对用户需求做更细致的分析，对软件的实用程度做一定估量。

2.计划

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

陈2：很多事情没有做完，因为第一次做没能很好地预估所有细节，加上使用的新技术有很多不确定因素，比如我就不知道为什么我的电脑并不能reload (╯‵□′)╯︵┻━┻

石：计划赶不上变化，最初计划是在Alpha版本开发结束后进行iOS和Android版本的同步上线。但是目前来看，中间选择座位和房间设置还有没有解决Bug，界面也没有达到可以面对用户无情的指责的地步。。。主要还是因为高估了我们上手一个新技术的时间，一共一个月的开发中可能有三周的时间都花在了熟悉新技术，验证新技术上，留给我们开发的时间已经不多了。虽然最后加班加点赶回了很多进度，但是离上线还有那么一周左右的工作量。

韩：没有。实际的工作量比想象中要大很多，原计划是发布软件的，现在并没有到能发布的程度。

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

陈2：好像没有

石：可能自己在学习方面应该尽快上手，不应该看了那么多的是讲解视频和博客，因为最后都差不多忘了。

韩：中间看了一些html及html内嵌javascript的知识，回想起来其实没什么必要。

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

陈2：有的有，有的没有。比如某些东西我们都是新学的，所以不知道怎么定义清楚。比如有个任务是完成某个页面，实际上我们的大多数时间都花在完善自己负责的页面这一块了，并没有拆成任务。这个怪我。。后期并没有很好地拆分任务

石：这点做得并不够好，后面赶进度的时候大部分都是自己在完成自己负责的部分的改进，并没有很好的分拆每一项任务。

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

陈2：除了我的破电脑，除了大作业之间的相互冲突，其他基本上没有。

石：还是之前说的，学习时间大大超出了预期，还有之后的编译实验，压缩了做项目的时间。

韩：大体是按计划进行。意外就是前面提到的任务量过大，由于开始计划时大家经验都不足，没有准确估计到实际所需时间。

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

石：如果说有的话，就算是从第四周周末到项目展示的周四这几天的时间吧。最后项目能差不多做完，对亏了这几天的缓冲区，我们在缓冲区的时间中做出了卓越的工作。

2.6 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

石：将来会留下更多的缓冲区使得我们的项目推进的更从容。因为Alpha阶段毕竟学习占去了三周的时间。

韩：如果可能的话还是希望缓冲区多一些的。。（这里我理解的缓冲区是休息的时间）。。毕竟还有编译课设。。

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

陈2：早一点发现自己的电脑不能开发reactnative

石：关于计划，我觉得如果能重来一遍，我会在最开始时规划时定义更详细的每日计划，这样能够更好的控制项目的进度

韩：尽管可能做的不是很好，但是我们依旧体验到了为一个软件工程做计划的流程。如果重来一遍，我们将更细致地规划每一个阶段。

3. 资源

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

石：在人员资源上，我们小组只有四个人，而且我们的任务相当庞大，这就导致了我们时间的紧张和工作的繁忙。上天多给我们几个人吧。。。

在开发资源上，很多技术文档都是英文，也有很多甚至没有技术文档，所以自己摸索的东西很多。

在相应的设备资源上，我们有一个组员的电脑一直没有能够装上开发环境，只有一台电脑开发安卓端，一台电脑开发iOS端，一台电脑开发后端，有时候有些局限。而且iOS开发者账号还需要自己买，服务器也不能方便的外网访问。这些都只能自己解决也占用了很多时间。

陈2：我们组是人最少的一组。

我的电脑不能用来调试。所以后来我只能干写代码然后到韩青长电脑上调试。

新技术有一些玄学问题。

其他资源，比如服务器、开发者账号之类的，有点麻烦。

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

陈2：一开始没有写代码的时候，估计的精度还行，写代码之后，精度就崩坏了

石：最开始大部分任务估计也就是根据大概估计的时间来算的，实际完成的时候会发现难度大大超出预期，基本都要花接近一倍的时间来实现。估计精度并不高

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

石：上面也说了，基本上没有哪种资源是足够的。。。我们都是在克服一个又困难中走过来的。反而文案方面，是最简单而估计最准确的。

韩：不太够。因为开一局游戏需要至少8个人左右，不过我们打算用一些模拟器来代替，大概能完成测试要求。

对于不需要编程的资源确实是低估了难度，美工设计确实是需要更多时间的。

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

陈2：好像没有。。

石：文档方面我花的时间实在是很多。不过也没办法自己就是想的比较多。。。可能这方面能交给队友就好了。

韩：由于主要只做了开发方面工作，所以暂时还没有。

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

石：多找点队友啊！缺人的影响不是盖的。

韩：提前考虑所需要资源和人手。

4. 变更管理

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

陈2：是的。每日组会+组团刷夜+随时commit+pull+push+API

石：每天的小组会议（虽然后来够十次了以后就犯懒没有写会议记录），再加上后来的半结对编程，还有全部托管在GitHub上的代码和实时更新的API文档，所有组员都养成了良好的习惯实时同步。这点我们做的很好。

4.2 我们采用了什么办法决定"推迟"和"必须实现"的功能？

陈2：除了最基本的功能和用户最需要的功能，其他都是可以推的

石：我们着重于完成基本功能和几个之前的用户调查中用户反响较高的杀手级功能，因为有了调研，所以我们做决定的时候也更简单。

韩：用户需求和实现难度相结合。

4.3 项目的出口条件（Exit Criteria – 什么叫"做好了"）有清晰的定义么？

陈2、石：没有定义。

韩：使用时完整流畅，无明显bug。（自己的理解）

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

陈2：嗯。。但是并不是预案。。组团刷夜起了很大作用

石：是的，我们并没有预期到之前学习阶段的进度拖延，之后在分析了项目进度和目标后，果断采取了全员结对共同公关的方案，取得了良好的效果。

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

陈2：我们的后端很强悍。。随时都能满足前端需求

石：比如说后端，我们对于后端的需求经常修改变换，而后端能够一直非常好的完成前端的需求。

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

陈2：越早开始越好

石：计划总赶不上变化，在项目之初，有时候并不能很好的考虑到之后的变化，那么就先开始工作起来，等到慢慢熟悉，再变更起来也不是什么麻烦事。最重要的就还是不要有太多的畏难情绪，最重要的就是要动起手来。

韩：项目一开始就应在Github上管理，而不是中途才整合在一起。

5. 设计/实现

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

陈2：一开始讨论的，大家都有参与。是的。

石：设计主要是我来完成的整体的技术选型和架构设计的。这个不好评价自己，看看其他人是怎么说的吧。

韩：总体的设计是在一开始由团队所有人讨论完成的。之后每个人具体负责的部分主要是自己来完成设计。中间交互的地方也会互相商讨完成。

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

陈2：在开发的过程中慢慢学习，然后解决了

石：这个问题有些多，虽然在确定设计方案之后，我大致都进行了相应的技术验证，但是由于之前并没有了解，难免会出现一些模棱两可理解不清的问题。这些问题随着大家对于技术的熟悉了解都自然而然的解决了。

韩：随着项目进展不断商讨得出。

5.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

陈2：没有，原型图算吗？

石：这些工具没有用到，但是我们使用了MockUp软件进行了原型图的设计，不过最后看来实际做出来的结果和原型图还是有一些差距的。

韩：没有使用工具，暂时是手工实现的类似于单元测试的接口测试方法。

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

陈2：我写的页面Bug挺多的。。是不是最多我就不知道了。。
发布之前就发现了。。
因为不知道。。

石：在有关WebSocket通讯的方面Bug比较多，网络方面的Bug也是难免的，在发布之前就发现了加入房间和选座位部分的Bug，可能是异步服务器处理的问题。

韩：网络连接时的bug最多，主要是由于对react native对http和websocket调用的不了解，以及接口规定有一些缺陷。

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

陈2：没有复审，但是公共部分大家都检查了一下

石：因为是各自开发，并没有对其他人开发的模块进行代码复审。不过在程序中公共的数据处理部分，代码经过了三名前端开发人员的共同检查。

韩：代码复审是在完成每个部分就由开发者立即测试调整的，比较严格地执行了代码规范。

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

石：我觉得我们应该更好的从一开始就贯彻持续集成的理念，这样对于软件Bug的回滚以及错误管理都是一个很好的解决方案。

韩：如果团队人手充足的话，希望能有一个架构师，来专门负责项目的整体架构以及各个模块之间的连接情况。

6. 测试/发布

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

陈1：有。在我们的APP中，需要测试的接口分两种，一种是游戏开始前获取信息的HTTP请求接口，这种接口可以看成是静态的，比较简单，已经测试过了；另外一种就是游戏过程中进行实时通信的Websocket请求接口，因为这是在游戏过程中用到的，测试起来就非常困难了。想要测试一个接口首先就要提前设置好房间和用户的各种属性，然后再发送一个请求，看返回信息是不是期望得到的。目前来看只有通过这种方式，一个接口一个接口的测试。

韩：有。团队人手不足的情况下，每个模块在完成之后由开发者立即测试。整体完成之后，由测试人员进行网络连接测试以及整体流程测试。

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

陈1：暂时没有，因为前后端的接口还没有完全统一，还在不断的修改完善阶段。

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

陈1：听说有这种工具，但是还没有查阅过相关资料，还没有准备使用。

6.4 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

陈1：在服务端将受到的请求与发送的请求记录下来，事后进行统计分析。当然测试主要还是考虑的正常情况下能否正常运行，对于各种特殊情况的发生没有全面的覆盖到。在测试阶段增加对异常情况的处理。

韩：测试工作肯定是有用的。通过测试工作我们发现了同样的组件，在IOS上可以流畅运行，在Android上却出现卡顿现象，另外标题栏在IOS上不适配，这些我们都计划在Beta版本完善。

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

陈1：服务器是租的阿里云，可能会面临网络中断的问题，这样一来正在进行的游戏数据可能就会被清零，服务器也要不时的查看运行情况。