交流、项目管理及测试部分的规划
1.交流方式以及交流频率
因为平时大家都在一块自习，交流其实十分方便，计划每两天晚上开一个小短会，熟悉下队员之间相对进度，避免有人进度较慢卡住集体进度的现象产生，每一周开一次大会，确定一周目标，并作相应记录。
2.代码管理
充分利用GitHub，划分develop与master分支，细化工作，每个人建立开发者仓库，在个人仓库develop分支修改代码，个人审核与测试后，向管理者发送pull request，develop功能完善了，组内成员集体审核源仓库develop代码,完成测试review，全体成员无异议后合并进源仓库，发布新的版本前，可以在master分支分出hotfixes分支用于整个项目测试与bug修复，无误后并入master，发布新版本。
个人开发过程中，应该以充分细化功能，以创建feature分支，每次完成一个子功能就提交，避免出现bug回退产生不便。 可参考下图： 
3.进度监督、燃尽图、时间管理
大家相互监督，每周确立目标，由项目负责人对项目开发整体流程进行估计，并且每两天的小会集体批评拖后腿的组员，尽量使一周的工作量保持一致，燃尽图以剩余工作量为纵坐标，时间以周为单位进行绘制，尽力避免下图情况发生。 
前者时间分配不当拼命赶ddl，后者直接gg
4.需求变更管理
这是一个难以避免的问题，能做的就是尽力的明白用户的需求，做好需求分析工作。
确保开发人员与需求分析人员保持良好的沟通，做好需求变更管理。特别是对当前开发产生影响的应该紧急开会进行讨论并并决定。并且确定变更需求通知到每个组员，避免产生无用的工作量。
5.技术攻关
因为当前组员并没有相关的实际项目经验，所以技术的学习是必须的。
- 对专业领域的Overview，遇到新的技术尽快的了解其大概。
- 借助开源代码对问题进行进一步认识，降低学习难度曲线，甚至在协议允许的情况下直接作为api使用。
- 同自己的认识的技术大牛交流与请教，，假如恰好有这方面的人脉则是非常幸运的。特别是技术高手，一般用不了几句话就能把某项技术的关键问题描述清楚了。从这种交流中，我们受益匪浅。当然，交流之前必须对问题有充分的了解，避免出现低效的交流。但要注意，我们一定要在对该项技术有所了解之后，再去找专业人士交流。否则这种交流建立在信息严重不对称的基础上，就是极其低效的。对该项技术的初步了解，也是让我们能问出真正有效的问题的基础条件。
6.人员变动与外部事务处理
平时对组员代码进行充分的规范，并严格要求说明文档，假如真的由退课的同学，应提前安排好交接工作。
对于个人突发事务，个人应该进行合理规划，为了激发积极性，对于影响了团队开发进度的成员给与贡献分削减
测试计划
1.迭代开发、及时测试以及确定每次测试的时间节点，寻找测试对象相关
缩短项目的反馈周期，一经发布，尽快联系校内用户进行体验，按照反馈进行代码改动，且通过不断的沟通，还能减少对用户理解上的偏差减少误解，从而降低项目最终完结却发现用户不喜欢的风险。 测试的安排在上面代码管理已经声明，同时在粉丝群中进行内测，修复bug，无误后校内公测。节点为alpha与beta版本确定后。
2测试计划表，测试内容子项，测试意见反馈渠道相关
- 因为组内成员少，安排专门的测试人员不现实，每次组员完成相应的功能后，应自己编写测试样例，编写测试报告，每周组会内容将测试报告整合，由大家一同讨论有无测试盲区，无误后，整合进一份测试报告。
- 对于测试内容子项，应当在认为分配中以功能单元为划分，在产品发布前，以功能间的匹配连接为主进行测试
- 渠道问题，组内以周会为主，内测以粉丝群为主，公测时候应在ui中添加反馈渠道。