M1阶段事后总结
M1阶段的开发结束了。我们的努力得到了应有的回报，下面我们将针对M1阶段产生的一些问题进行分析和反思。
一.设想和目标
1.我们的app更像是一款针对北航学子的“知乎”应用。这款app可以实现基本功能：用户管理、搜索、分类、上传下载、用户贡献与交互等。
2.在alpha阶段，我们利用第一周的时间对学长的代码进行解读和分析，制定出相应的计划。我们认为制定计划的时间是非常充裕的，但是由于我们的经验不足，在测试原有APP的功能时出现了一些问题，导致后期修改原代码中的bug占据了过多的时间。
3.由于团队中只有一个人是真正做过安卓应用开发的，在制定大体计划时并没有产生多少分歧。可能在开发过程中遇到其他问题时，团队的核心技术人员会根据情况不同给出不同的解决方案。我们一直处于多沟通，多交流的开发模式，我认为这也是整个团队能够在alpha阶段取得阶段性成功的重要因素之一。
首先，由于我们的APP这周才正式完成，还没有将应用放在其他平台上推广，因此用户量比较少。但是我们对alpha阶段的成果进行使用测试的时候，基本的功能已经能够使用了。这也说明我们一个月的项目开发是成功的，尽管经历了一些波折。
如果历史重来一遍，我们可能一开始就会召集四个组的成员集中精力先修改bug。我们组的队员能力很强，但也花了将近10天的时间去修复。如果一开始就让四组同学一起商量分析修改bug，可能我们还会做的更好。
二.计划
1.我们原有的计划就是初步实现学霸网站的基本功能，事实上，在组员将近一个月的熬夜后我们也确实完成了。
2.一个月的开发时间，每一个人都在尽自己最大的努力去做好每一件事。我们只在过程中发现我们自己的一些不足，但是还没有发现哪件事做了无用功。
3.在并不熟悉项目的时候，每个人都是摸索着尽量不去纠结细节，只求做出大概的一个成果，在beta阶段再继续修复。
4.项目的计划是第一周解读代码，第二周和第三周进行软件开发，第四周进行测试，当然这是非常理想的一个状态。但是在开发的过程中我们遇到两个比较大的挑战，打乱了我们的计划。第一次挑战是在测试原代码的时候，发现的bug让我们的项目在10天内几乎没有进展。第二次挑战是在第三周周末的时候发现了一个连接数据库的重大问题，为了解决这个问题我们又花费了将近一周的时间去调整。究其原因，还是我们开发项目的经验不足，没有想到各方面的问题。但是这也成为我们今后项目开发的一个经验教训。
5.本来计划有三天左右的缓冲时间，但是在接连遭遇两个挑战后，我们的缓冲区没有了。庆幸的是，组员的技术很强，这才能让我们的软件如期发布。
6.在将近一个月的时间内，组员在项目上花费的时间是平均每天5-6个小时。核心技术人员平均每天将近十几个小时，远远超出了我们计划的工作时间。因为我们的软件已经能实现基本功能，因此下一阶段的主要任务就是修复bug。
三.资源
1.组员的能力强是我们项目最终得以成功的最重要的保证。最初我们可能还是低估了这个项目的难度，后期遇到的问题也着实给了我们很大的打击。
2.各项任务的最初分配是由核心技术人员讨论得到的。在开发过程中，PM根据每人每天的工作量酌情分配。
3.我们在开发的过程中就做了简单的测试，由于存在的bug确实比较多，我们打算在Beta阶段做更加细致的测试。
4.我们在项目开始前就经过会议讨论了每个人的强项，技术不行的就去认真写文档，技术能力强的就带领大家一起攻克一个个难题。
四.变更管理
1.我们在项目初期就建立了一个QQ群，方便大家随时交流。因为项目中有一位女生，和一名留学生，没法和其他组员随时碰面交流，因此QQ群的交流显得极为重要。
2.因为软件的基本功能确定，我们在决定一个功能是推迟实现还是必须实现时是围绕基本功能确定的。和基本功能相关的，影响alpha阶段成果的功能是必须实现的。
3.我们在认定软件的出口条件时以是否能够实现基本功能为准则，如果能够实现，那么可以发布。
4.对于之前遇到的一些问题和挑战，我们都及时召开会议商讨解决方案。因为在项目中，我们在前端设置了两名人员，后端有两名人员，还有一位机动人员，相对能力更强一些，可以随时处理一些应急事件。
五.设计/实现
1.设计工作在项目开始的第一周结束的时候由团队中熟悉安卓应用开发的人员完成了。因为第一周开会的时候计划先看一周代码，在这一周的时间内大家互相帮助尽可能多的读懂代码，然后再进行开发。我们的项目可能在设计上不用太费工夫，需要我们考虑的是每个人的分工。
2.用了3-4天学习服务器端配置并实现。
3.由于上一届的UI是在是不够美观（组件过于零碎、风格不统一），我们决定对UI代码进行重构。
4.由于我们不了解学长们的数据库规格，所以花费较长时间修复后端的Bug。
5.因为开发时间非常长，导致没有进行深入测试，将在下一阶段进行。
6.前端后端分别有两名开发人员，并且一名机动开发人员可以随时互相审阅代码，查出漏洞。
7.测试阶段，没有开发周期较长，超出预期，所以没有做单元测试，仅做了真机测试。
六.测试/发布
1.初期我们确实制定了一个测试计划，预计是在第四周进行。但是开发在第四周才结束，并且开发过程中做了一些小的测试，所以最后计划没有实现。
2.暂时还没有进行正式的验收测试。
3.发布的过程中由于发布平台的身份信息需要审核，发布app后也需要进行严格的审核，经过若干次修改提交信息后，我们终于在360移动开放平台发布。
经历了萌芽和磨合阶段，我认为我们的团队正在逐步迈向规范阶段。M1阶段结束的时候，我们看到了我们付出的回报，完成了既定的计划。
对比敏捷开发的原则，我认为我们团队做的最好的就是“以有进取心的人为项目核心，充分支持信任他们”和“无论团队内外，面对面的交流始终是最有效的沟通方式”。我认为我们最后能够在有限时间内开发出一款功能如此多的应用不仅在于项目核心人员的技术能力强，更是因为我们充分的互相信任以及频繁的沟通。试想，如果我们在开发阶段没有相互理解，沟通，在bug产生的时候没有交流，而是一味的自己闷头苦想，可能软件的发布又会有所拖延。在接下来的一个阶段，我们将继续保持我们的热情和责任心，迎接其他的挑战！
M2阶段的计划：
1.继续完善功能 ： 修改UI、 完善用户个人信息（如显示用户提过的问题、回答过的答案）、增强交互能力（如：用户注册时，邮箱已被注册，需要用户更换邮箱）。
2.主要任务是和online系统的小组进行数据合并，同时我们两个小组已经决定公用一个服务器，这样数据可以共享，同时也可以对第一、二组的数据要求更为清晰，但也存在巨大的团队之间协同合作的问题，两个小组共同开发，这会给沟通交流带来更大的挑战。
3.设计开发文档
4. 修复已知的bug，如闪退。
4.进行单元测试
