前两天基本属于前期准备，所以把三天合并成第一天。
一、站立式会议照片
二、燃尽图
三、项目进展
1.界面
- 登陆界面已经完成
- 文件选择界面正在写
2.登陆模块
- 基本完成。但需要跟合作队伍协商，并写出API
3.Excel处理
- 文件的导入导出基本功能基本完成。目前只能获取固定路径的文件和导出到固定的路径。只能导入报课表，教师表的导入未实现
之前有提交，但由于提交了过多没要求的文件，被我拒绝合并。由于530同学要完成linux作业，且没有掌握好github的使用，第二次提交还没到来……
4.服务器
- 已经大致了解服务器的工作方式及API的编写，正在测试
5.PM
- 项目的细化和分配已经有思路。参考了构建之法P166，结合使用自底向上和回溯，将最近两天要做的事情安排出来。发到讨论组。
- 懂得在发布issue之前跟所要负责的队员协商
- 任务耗时估计相比一开始更准确了些
四、问题困难
-
队员的android开发基础较差，学习速度不快。
这就导致我给出的耗时估计如果太多，在所剩的时间中能完成alpha版预定的功能的概率较小；如果耗时估计太少，这样也不符合实际，队员需要先学一段时间，才有办法去实现功能。
给出时间已经尽量偏多，把学习知识的时间也算进去，但仍然达不到较好的效果。虽然在发布issue之前，有和队友协商，但队友虽然对给出的耗时估计没有意见，但在耗时估计偏多的情况下，实际耗时仍超出耗时估计。 -
剩下的时间并不多。
我统计了一下团队成员在剩余的九天中（从29日开始）所能空出的时间，大概每个人总的能空出40小时。这不包括队员面对各种意外时，还要扣除预估的空余时间去处理别的事情。 -
队员碰到问题没有及时沟通。
整个团队都有这个问题。暴露出PM没有经常和队员沟通的问题。
五、心得体会
- 在项目开始之前，就应该先确定alpha版本要实现哪些功能，哪些功能要留在beta版本实现。
用Excel表格将功能列出，列出每一天要做哪部分。 - 不要抱怨队友（虽然有时候会习惯性地说两句），解决问题才是关键。
- 跟队友解释清楚问题需要耐心去理解去阐述，等队友解释完，而不是轻易地否定。
- 不能把时间都花在个项目上，因为这样效率反而更低。脑力劳动者的休息不是去睡觉，而是思考不同领域的问题。所以不要翘课，上课该听讲还是要听。