设想与目标：
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还可能出现无法显示图片的问题，这个问题至今尚未得到解决。
总结：
- 经过了一段时间的Alpha冲刺，我们在安卓开发上有了一定的经验和基础，学习到了很多的知识，我觉得这能够帮助我们在beta阶段中更好的进行开发。但同时也暴露出了一些问题，在Alpha冲刺中，我们花了大量的时间在编码和学习怎么编码上，导致我们对一些细节和编码以外的的东西不够重视，比如代码的规范，我觉得在beta冲刺中，我们应该多多考虑代码规范等编码以外的东西，不要只是为了写代码而写代码。同时应该进一步加强沟通，有些想法或者事情发生了变化要及时得进行讨论，不然在一段时间后要进行修改的话需要耗费成倍的时间和精力。