1.我们组决定选用Github flow的工作流程
（1）Github flow工作流程简介
它只有一个长期分支，就是master，因此用起来非常简单。
官方推荐的流程如下。
第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。
第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。
第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码。
第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可。）
（2）选用Github flow工作流的原因分析
Github flow 的最大优点就是简单，对于"持续发布"的产品，是最合适的流程。它的主要缺点是master分支的更新与产品的发布是一致的。也就是说，master分支的最新代码，默认就是当前的线上代码。本次课程作业的项目是一个简单的小学生四则运算系统，除本组人员进行开发测试外一般不会有用户去使用它，所以对于版本发布跟踪没有高要求。只要能够保证最后项目开发完成，基本功能都实现，能够正确运行就可以了，所以决定用Github flow这种比较简单的Github版本更新流程。
2.代码规范、Github提交源码的标准
编码规范在项目开发和维护的整个过程中都起着重要的作用，规范的编码能够让代码易读、易懂，降低后期维护和debug所需要的时间，提高团队效率。
本组的代码规范主要有：
（1）格式规范。包括缩进、每行代码的长度、“｛”和“｝”在不同函数语句中的位置及换行要求、空格的使用等。注：有些可以通过使用eclipse中的Format方法（快捷键：Ctrl+Shift+F）进行自动格式化。
（2）注释规范。注释要保持和代码同步，简明扼要，易于理解。类的注释要给出一定的描述，方法注释要表明它的主要功能，一些必要的变量、分支语句等也要给出一定的描述说明。同时要注意注释的书写格式，一般失效废弃的代码采用块注释简写形式。在测试时插入的输出先采用特殊的注释方法，以便后期删除。
（3）命名规范。不论是常量、变量、类、还是包的命名都要简单易懂，富有描述性，使命名是有意义的。命名采用一个名词的方式，大小写混合，尽量使用完整的单词。但是，类名要所有首字母大写；变量名第一个单词首字母小写，其后的首字母大写；常量名所有字母都大写，单词间用下划线隔开；方法名第一个单词首字母小写，其后的首字母大写；接口名都以大写“I”开头，其后所有单词的首字母大写。
向Github上提交源代码的要求：保证代码能够正确运行，没有错误提示。
3.本周的例会是在周四（22号）进行的，主要内容是一起将上周的需求分析进行了细化，讨论了开发要运用的工具、数据库的设计，以及人员的分工情况。任务分配主要是依据每个人之前的项目经历，之前积累下的经验选择自己最擅长的部分进行，以提高项目完成的效率。例会中还讨论了项目的整个开发流程以及各个重要的事时间节点，每个成员再根据情况细化安排自己的工作。
下面是周日（25号）在微信群里和大家确认工作进度的截图：
4.小组成员的角色，细化项目需求、时间计划、列出产品积压工作项和预计开发时间
项目需求在开会讨论时进行了细化，并在Github上同步更新了。细化的主要内容如下：
功能性需求
注册登录需求
● 用户注册登陆时,需要输入用户名和密码.
● 用户名不能为空,不能超过200个字符,用户名可以是数字字母和下划线组成. 不能与现有账号名相同。
● 密码不能为空,不能超过20个字符.
可用性需求
系统易用性
系统首页 有用户名和密码的输入框,以及登陆和注册按钮
用户登录系统成功后的页面 有练习和查看功能,以及页面有该系统的简要说明
注册页面 有用户名和密码的输入框以及注册按钮
练习页面 题目类别的选择包括简单四则运算、混合运算、真分数运算,然后显示相应题目
得分页面 显示该用户的名称时间、用时、得分
消息提示 每次点击按钮后如果没跳转页面,都会出现提示信息,指导用户操作.
本组的团队合作模式采用的是业余剧团模式，组长相当于导演，负责中央指挥，其他组员有各自的角色分工，配合一起完成整个项目。下面是我们组基本的分工情况：
整个项目的需求分析，数据库的设计以及功能模块的划分等由全体成员共同讨论决定，各个成员的分工如下：
（1）杨杨：组长，主要负责团队间的沟通，任务分配。项目中的角色为程序员，主要负责整个项目的前端代码编写，以及登录、注册、找回密码等功能的实现。
（2）龙秋娴：组员，在项目中的角色为测试员，负责测试工作。包括单元测试、功能测试、整体系统的测试，设计测试用例的及测试结果报告的编写。
（3）谭昭玮：组员，在项目中的角色为程序员，负责个人信息详情、各年级的加减乘除运算训练、查看训练历史纪录等功能模块的实现。
（4）朱翔宇：组员，在项目中的角色为UI 设计员。主要负责系统的UI设计，给出各种原型图，以及项目中其他文档的纪录、整理和编写。
项目开发计划：
因为本项目需求相对简单，可以分阶段进行，阶段间存在因果关系，开发过程中也不需要用户的参与，项目需求都是预先确定好的且不会改变，所有我们组决定采用瀑布模型。按照需求分析－架构设计－详细设计－编码和调试－测试－运行的过程一步步进行，编码和测试这两个阶段会存在回溯并尽量保持同步进行。
预计开发时间为5周，具体工作时间安排见下面的甘特图。