阿尔法冲刺——Postmortem会议

设想与目标

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

这个问题，我们觉得我们的软件目标还是比较明确的，在SRS中也给出了典型用户和典型场景的清晰的描述。

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

这个并没有，由于阿尔法项目时间短，人员少，经验的不足，导致很多app上的问题难以得到解决，项目进展的比较缓慢，有些功能并没有按预期计划实现。

3.团队在计划阶段是如何解决组员对于计划的不同意见的？

对于这点，我们总是保持尊重制作每个部分成员的意见，出现严重争议时候由组长协商，听从组长的安排。

---

计划：

1.是否我们有明确且合理的分工？

在初期，我们通常都是两个人看着一个人做，或者一个人等待的另一个人分配下来的任务，我们没有做到三人三线程，这也是导致了我们项目发展慢的原因之一。我们没有做到三人三线程的主要原因是项目发展初期各自安卓知识匮乏导致的各种问题多和繁琐，大家比较喜欢热衷于一起解决，讨论时间大于独立完成时间。我们需要通过一段适应来增强安卓开发的能力与独立研究的能力。在项目发展中期阶段，我们便有了明确的分工，因为大家各自成熟，也能够各自承担各自部分的内容。

2.有没有发现你一些事没有及时和组员讨论，在后续浪费太多时间去更改的地方？

有的，例如冗余的activity被碎片取代。

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

这一点我觉得是我们最该去深思的一件事情。例如我们写好的很多Demo在虚拟机上畅通运行，给了我们真机一定能够顺利运行的错觉。我们的最大痛点在于“制作功能模块的Demo时，没有进行虚拟机和真机联合测试”，在这十天的冲刺中，我们把我们能够实现的东西想的过于美好，各个模块的Demo自以为很成功，但是在真机和虚拟机差异下暴露出来的兼容性问题也越来越多。

---

变更管理

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

是的，由于我们是舍友，联系和交流都很方便且直接。

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

根据我们实际的能力和时间的允许性。

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

没有考虑，如果真的发生了，只能负责各模块人员或者空闲人员硬着头皮上了。

---

设计与实现

1.是否有很明确的变量名和包名的规范？在项目各模块拼接中是否遇到了问题？

这个问题其实很蠢，但恰恰手忙脚乱之中，我们在这点上并没有做得很好。幸运的是我们组的组员多数使用中文命名，因而并没有在重名上给我们带来太多的困扰，但没有发生问题不代表没有问题。在项目拼接中，由于我们在暴露接口的部分还是做的很好，最终在项目拼接上并没有给我们带来太大的困扰。

2.在设计过程中，如何解决遇到了难以解决的问题？

百度百度百度，以及再百度，如果不行，那么换个搜索引擎继续。在短时间的冲刺里，我们没有考虑去图书馆翻阅书籍去解决问题。

3.什么功能产生的Bug最多，为什么？

足迹功能吧，由于我们借用了百度开发者平台的百度地图，对于该地图的API我们并不熟悉，导致了在实际使用过程中会可能出现定位后软件持续假死的状态。

---

测试与发布

1.团队是否有一个测试计划？最终按照该测试计划实现了吗？

我们有一个测试计划，但是由于阿尔法冲刺项目并没有如期完成，有些功能模块并没有达到测试要求。

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

兼容性问题。由于我们的UI设计没有用到框架，所以在不同机型上显示的情况也不尽人意。有些控件虚拟机上看起来是正的，实际真机上是歪的。尤其是在MIUI系统上，ImageView还可能出现无法显示图片的问题，这个问题至今尚未得到解决。

---

关于我的作死：

就对于邹欣老师的问题给出我自己的想法。顺带也是对我们自己的项目没有使用源代码管理工具的一个总结。问题链接链接：源代码管理

当然我们的项目不会有"如果你的团队来了一个新队员，有一台全新的机器，你们是否有一个文档，只要设置了相应的权限，她就可以根据文档，从头开始搭建环境，并成功地把最新、最稳定版本的软件编译出来，并运行必要的单元测试（在这过程中，不需要和老队员做任何交流）"这种情况的发生，如果老师没有提示，大概我们也不会想到吧。

我们承认我们之间的源代码的交流方式就是简单的QQ和U盘，对还有U盘，这大概就是既是舍友又是队友的好处吧emmmmm...虽然我们想过用github分支来实现我们源代码的管理，但是队友对github分支不熟悉，加上锐捷网下github说崩就崩的情况在所难免，当然最主要的原因是我们没有意识到源代码管理这种工具的重要性，所以我们并没有采用这样的一种方式。

直到我们最后做一个项目的拼接整合的时候，我们才开始慢慢觉察到github和coding.net这类源代码管理工具的重要性，由于我们在拼接时候需要频繁的做一些局部修改，来一点点磨合我们的整个项目，然而这个时候，我们采取的是A同学坐到负责整合项目的B同学的电脑前，啪啪啪打好代码走人，B同学看着A同学指指点点，然后等待A同学做完后，B同学继续做整合。这样一来，B同学因为等待A同学而停止工作，效率低。再比如A同学突然有一个点子，需要更改项目，却要等待B同学的回复，并且让B同学上传当前的代码，这样一来，他们的的确确一起工作了，然后事后却不知道对方对原来的代码做了哪些的改动，这时候又要AB同学努力地互相交流一番，又浪费了时间。 假设我们有一个源代码管理工具，我们就能够方便地及时提交自己修改的代码，并且团队成员也很容易知道你改了哪些地方，既节约了自己的时间，也方便了队员的编码。

回归到我在冲刺总结中写到的：我们的团队很难形成很强的团队向心力，是我们没有办法同时对同一个文件进行不同模块的编写，即三人三线程工作，这是我们今后在beta项目中需要总结和进步的地方。

最后附上github、coding.net、code.csdn.net的比较：

• github ：不用多说，最大的优点是上面拥有遍及全世界的丰富的开源代码，但是国内用起来未必方便，上述讲过的不知是国情问题还是运营商的问题，并不是每时每刻都能很快速且方便上这个github，没事崩个一两天也是很正常的。还有一点就是不能够不要钱地开设私有的仓库，也是因为这点很多团队不会采用github来管理自己项目的私有代码。用知乎上的一句话来说"Github的价值在于它是人类软件的基因库"，它的地位无可取代，当然谁也几乎不可能被超越。

• coding.net ：个人认为是国内最一流的仓库吧，当然在我心里地位无可取代，个人感觉碾压gitcafe。中文，而且网站界面令人神清气爽，一个词“舒服”，据说国内非常多的团队痴迷使用coding.net。当然因为在国内，所以访问速度不必多说，拥有免费的两个私有仓库，也是满足了多数团队的需求。但是没有github的丰富度。

• code.csdn.net ：中文版。界面简洁算是一个优点，但并没有打动我。它的最大优点是拥有大于三个的免费私有仓库（至于是不是不限量的我就不得而知了）在国内据说并没有很火，也没有github的丰富度。

---

写在最后：

• 我们对安卓开发的态度经历从充满热情到失去信心，再到因为deadline重拾热情的过程。在整个过程中，让我们感触最深的是安卓开发所带来的问题远比想象的多。某种意义上来说，deadline反而给了我们绝望中的力量。

• 在安卓开发中，有些东西，不仅仅是不会做的问题，更是无从下手的问题，这会让我们很难受很难堪。到deadline迫近的时候，你所谓的“想法设法”最终还是变成了我要在最可能途径上更加的努力——百度百度百度以及再百度。所以，在冲刺时候的沮丧带来的懒惰心理，最终还是影响到了deadline到期时候的实际进度。有时候真的发现，开始时候的懒惰并没有为你后续带来多少的轻松，我们多多少少缺乏对整个开发过程的适应性。这次开发，给我们带来的最大的收获我觉得不是我们会用了android studio还是学了UI设计还是会了java语言，而是你真真切切感受到了这样的一个开发过程，给了你一个作为程序开发者的适应能力，给了你反思自我、反思整个开发过程的机会，这样的第一次是弥足珍贵的。

• 整个项目中，我们发现我们百分之七十以上的代码源于借鉴。所以安卓开发给我们带来的另一个重要收获应该就是锻炼我们如何从庞大的网络资料库中找到这些API，并且落脚点在如何正确使用这些API。在整个项目中，我们发现实际上因为使用方式不当导致程序崩溃远比因为逻辑问题而导致程序错误结果出现的概率高的多。