【Beta】Daily Scrum Meeting总结

一、项目预期计划和现实进展

更换网络请求框架为okHttp	完成
补充和完善服务器的API	完成（可与web端互连）
补充和完善app与服务器交互的类和方法	完成
完善app界面数据绑定	完成（所有涉及到的数据都成功显示到界面）
完善app界面元素（学期控件，系负责人所负责专业控件）	部分完成（修改信息的地方，没有系负责人所负责专业控件）
完善app界面逻辑	部分完成（有些处理顺序安排得不够好）
完善Excel导入导出（特别是导出）	部分完成（暂不支持导入客户提供的xlsx格式教师表）
更换数据库框架为OrmLite	未更换（使用了另一套方案来解决数据库问题）
适当重构代码，使得代码简洁易读	小部分重构（以完成需求为主）

待解决的问题：

导出Excel时，我们是直接放一个只有这三行数据的xls文件在raw文件夹里面，然后复制这张表并填充数据。这样前三行是跟导入的表一致的（如果一学年只有上下两个学期的话）。这可能与老师的要求不符，因此需要将其更换为从数据库中取出。
当只有一个任务时，删掉该任务，任务列表会保留这个任务，点进去程序会崩溃。
到了截止时间后，不能操作。这个功能还未实现。
删除教师时，列表没有更新。
发布报课任务后，教学办无法修改任务信息（如截止日期）。

二、过程体会

先附上燃尽图（本来想从第七天冲刺里直接拿出来的，结果发现没有燃尽图！吓得我赶紧补上）
整个beta版本的开发过程还算是比较顺利的。但是正如你所见，燃尽图从2号到7号没有动。因为这个阶段里有各种考试，尽管如此，其实也不应该一个Issue都不解决。考试是岔开的，没有考试的同学应该可以继续开发。至于站立式会议，可以讨论完然后把结果告诉其他队员（当时没有这么想，所以决定停工。至于停工期间是否继续开发由自己决定）。
这也引发了一个问题，就是节奏断了。主要有两个表现：
1. PM对项目的整体把握迅速降低
  - PM如果对项目的整体把握不足，会给项目带来很大的威胁。PM有一段时间根本不清楚项目进展到怎样了，接下去要做哪些事情。这些都是通过开站立式会议来理清的，但也仅限于一时，下次开会还是要解决这些问题。所以开会的时候经常会问 “xx你正在做哪一部分？做到什么程度了？接下去需要做什么？” 然后根据回答来判断是让他继续做下去，还是让他先去处理更重要更紧急的任务。
    在这样的情况下，PM应该让队员说出大致有哪些部分没有完成，然后去查看相关代码，把握全局。
2. 队伍开发积极性降低
  - 队伍开发积极性降低，会拖进度。在紧绷的状态下突然放轻松，不好收回来。这时候连续来几发站立式会议，就好多了。与此同时，Issue一定要尽可能写好！你跟队友说了半天要做什么，是不够的。一个Issue丢上去，把要做的事情描述清楚（不用很详细），然后写上注意事项。这样开发的时候，有Issue做参照，会比较清晰。
相较于Alpha版本的Issue，感觉Beta版本的Issue描述得更好，粒度也分得更细一些。
Alpha版本时，我们在某一些功能上会有争论。但是Alpha版本结束时，队员之间都为和谐交流做了一些沟通。

我们认为，争论的起因是受到了否定而导致情绪化，主要原因是理解不了对方想表达的意思。

我们协商提出了解决的方法：尽量确定对方能够理解你想表达的意思，如果觉得对方没有理解清楚，那么重复描述一遍；尽量少用否定的词语，先摆出问题所在，然后提出自己的想法。

效果还是不错的。Beta版本基本没有Alpha版本那样的冲突出现，在对方偶尔说出否定词语的时候，也能够表示理解，而不是情绪化。

毕竟是团队合作完成一个项目，有冲突是正常的。如果我们没有在Alpha版本之后及时沟通，可能Beta版本冲刺的时候还会出现各种冲突，这是很糟糕的。

对了，还有一点就是能用画图来描述的就画出来。一图胜千言！

这次的七天冲刺（实际上开的会不止七次），需要处理的东西很多，而且更复杂。光是完成功能就够辛苦的了，测试就基本没有做。冲刺期间又被考试虐了/(ㄒoㄒ)/~~
在beta版本的开发过程中，我们对版本管理进行了一些改进。这次的改进主要在commit时的描述以及Pull Request的命名。我们将Pull Request命名为Issue的编号，这样能更清楚都做了哪些任务。（我忘了可以在前面加 fixes 来同时关闭Issue，不然就可以把这点用上去。GitHub官方教程：Closing Issues via Pull Requests）
感谢各团队成员努力。相信各位都从这次冲刺中学到了新的知识，无论是编程还是其他。特别要点赞的是，各位没有那种“我是来抱大腿混学分”的想法。都是发自内心地想为项目做贡献，想把这款APP完成。很幸运能与你们组队。