团队博客目录：FTD团队博客目录
一、项目预期计划和现实进展
| 更换网络请求框架为okHttp | 完成 |
|---|---|
| 补充和完善服务器的API | 完成（可与web端互连） |
| 补充和完善app与服务器交互的类和方法 | 完成 |
| 完善app界面数据绑定 | 完成（所有涉及到的数据都成功显示到界面） |
| 完善app界面元素（学期控件，系负责人所负责专业控件） | 部分完成（修改信息的地方，没有系负责人所负责专业控件） |
| 完善app界面逻辑 | 部分完成（有些处理顺序安排得不够好） |
| 完善Excel导入导出（特别是导出） | 部分完成（暂不支持导入客户提供的xlsx格式教师表） |
| 更换数据库框架为OrmLite | 未更换（使用了另一套方案来解决数据库问题） |
| 适当重构代码，使得代码简洁易读 | 小部分重构（以完成需求为主） |
待解决的问题：
导出Excel时，我们是直接放一个只有这三行数据的xls文件在raw文件夹里面，然后复制这张表并填充数据。这样前三行是跟导入的表一致的（如果一学年只有上下两个学期的话）。这可能与老师的要求不符，因此需要将其更换为从数据库中取出。
当只有一个任务时，删掉该任务，任务列表会保留这个任务，点进去程序会崩溃。
到了截止时间后，不能操作。这个功能还未实现。
删除教师时，列表没有更新。
发布报课任务后，教学办无法修改任务信息（如截止日期）。
二、过程体会
先附上燃尽图（本来想从第七天冲刺里直接拿出来的，结果发现没有燃尽图！吓得我赶紧补上）
整个beta版本的开发过程还算是比较顺利的。但是正如你所见，燃尽图从2号到7号没有动。因为这个阶段里有各种考试，尽管如此，其实也不应该一个Issue都不解决。考试是岔开的，没有考试的同学应该可以继续开发。至于站立式会议，可以讨论完然后把结果告诉其他队员（当时没有这么想，所以决定停工。至于停工期间是否继续开发由自己决定）。
- 这也引发了一个问题，就是节奏断了。主要有两个表现：
- PM对项目的整体把握迅速降低
- PM如果对项目的整体把握不足，会给项目带来很大的威胁。PM有一段时间根本不清楚项目进展到怎样了，接下去要做哪些事情。这些都是通过开站立式会议来理清的，但也仅限于一时，下次开会还是要解决这些问题。所以开会的时候经常会问 “xx你正在做哪一部分？做到什么程度了？接下去需要做什么？” 然后根据回答来判断是让他继续做下去，还是让他先去处理更重要更紧急的任务。
在这样的情况下，PM应该让队员说出大致有哪些部分没有完成，然后去查看相关代码，把握全局。
- PM如果对项目的整体把握不足，会给项目带来很大的威胁。PM有一段时间根本不清楚项目进展到怎样了，接下去要做哪些事情。这些都是通过开站立式会议来理清的，但也仅限于一时，下次开会还是要解决这些问题。所以开会的时候经常会问 “xx你正在做哪一部分？做到什么程度了？接下去需要做什么？” 然后根据回答来判断是让他继续做下去，还是让他先去处理更重要更紧急的任务。
- 队伍开发积极性降低
队伍开发积极性降低，会拖进度。在紧绷的状态下突然放轻松，不好收回来。这时候连续来几发站立式会议，就好多了。与此同时，Issue一定要尽可能写好！你跟队友说了半天要做什么，是不够的。一个Issue丢上去，把要做的事情描述清楚（不用很详细），然后写上注意事项。这样开发的时候，有Issue做参照，会比较清晰。
相较于Alpha版本的Issue，感觉Beta版本的Issue描述得更好，粒度也分得更细一些。
- PM对项目的整体把握迅速降低
Alpha版本时，我们在某一些功能上会有争论。但是Alpha版本结束时，队员之间都为和谐交流做了一些沟通。
我们认为，争论的起因是受到了否定而导致情绪化，主要原因是理解不了对方想表达的意思。
我们协商提出了解决的方法：尽量确定对方能够理解你想表达的意思，如果觉得对方没有理解清楚，那么重复描述一遍；尽量少用否定的词语，先摆出问题所在，然后提出自己的想法。
效果还是不错的。Beta版本基本没有Alpha版本那样的冲突出现，在对方偶尔说出否定词语的时候，也能够表示理解，而不是情绪化。
毕竟是团队合作完成一个项目，有冲突是正常的。如果我们没有在Alpha版本之后及时沟通，可能Beta版本冲刺的时候还会出现各种冲突，这是很糟糕的。
对了，还有一点就是能用画图来描述的就画出来。一图胜千言！
这次的七天冲刺（实际上开的会不止七次），需要处理的东西很多，而且更复杂。光是完成功能就够辛苦的了，测试就基本没有做。冲刺期间又被考试虐了/(ㄒoㄒ)/~~
在beta版本的开发过程中，我们对版本管理进行了一些改进。这次的改进主要在commit时的描述以及Pull Request的命名。我们将Pull Request命名为Issue的编号，这样能更清楚都做了哪些任务。（我忘了可以在前面加
fixes来同时关闭Issue，不然就可以把这点用上去。GitHub官方教程：Closing Issues via Pull Requests）感谢各团队成员努力。相信各位都从这次冲刺中学到了新的知识，无论是编程还是其他。特别要点赞的是，各位没有那种“我是来抱大腿混学分”的想法。都是发自内心地想为项目做贡献，想把这款APP完成。很幸运能与你们组队。
三、组员分工及工作比例
团队统计
| 版本 | Alpha | Beta |
|---|---|---|
| Issue（有效数） | 45 | 44 |
| Pull Request | 45 | 51 |
| Commit | 229 | 150（有效79） |
个人统计
| 成员 | 502 | 509 | 517 | 530 |
|---|---|---|---|---|
| Issue（Alpha） | 7 | 8 | 21 | 9 |
| Pull Request（Alpha） | 7 | 4 | 21 | 9 |
| Issue（Beta） | 10 | 15 | 11 | 8 |
| Commit（Beta） | 23 | 21 | 18 | 17 |
| Pull Request（Beta） | 14 | 18 | 10 | 9 |
最终确定的百分比贡献
502：20%
509：34%
517：20%
530：26%
四、合照
我们队目前只有三个成员获得了黄衬衫，暂时从别人那借了一件 _(:з」∠)_
可以对比我们第一次团队展示
115
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
