【Alpha】Daily Scrum Meeting第一次

一、Daily Scrum Meeting照片

---

二、Burndown Chart

---

三、项目进展

1. 界面

   • 登陆界面已经完成
   • 文件选择界面正在写

2. 登陆模块

   • 基本完成。但需要跟合作队伍协商，并写出API

3. Excel处理

   • 文件的导入导出基本功能基本完成。目前只能获取固定路径的文件和导出到固定的路径。只能导入报课表，教师表的导入未实现

   之前有提交，但由于提交了过多没要求的文件，被我拒绝合并。由于530同学要完成linux作业，且没有掌握好github的使用，第二次提交还没到来……

4. 服务器

   • 已经大致了解服务器的工作方式及API的编写，正在测试

5. PM

   • 项目的细化和分配已经有思路。参考了构建之法P166，结合使用自底向上和回溯，将最近两天要做的事情安排出来。发到讨论组。
   • 懂得在发布issue之前跟所要负责的队员协商
   • 任务耗时估计相比一开始更准确了些

---

四、问题困难

1. 队员的android开发基础较差，学习速度不快。
   这就导致我给出的耗时估计如果太多，在所剩的时间中能完成alpha版预定的功能的概率较小；如果耗时估计太少，这样也不符合实际，队员需要先学一段时间，才有办法去实现功能。
   给出时间已经尽量偏多，把学习知识的时间也算进去，但仍然达不到较好的效果。虽然在发布issue之前，有和队友协商，但队友虽然对给出的耗时估计没有意见，但在耗时估计偏多的情况下，实际耗时仍超出耗时估计。

2. 剩下的时间并不多。
   我统计了一下团队成员在剩余的九天中（从29日开始）所能空出的时间，大概每个人总的能空出40小时。这不包括队员面对各种意外时，还要扣除预估的空余时间去处理别的事情。

3. 队员碰到问题没有及时沟通。
   整个团队都有这个问题。暴露出PM没有经常和队员沟通的问题。

---

五、心得体会

1. 在项目开始之前，就应该先确定alpha版本要实现哪些功能，哪些功能要留在beta版本实现。
   用Excel表格将功能列出，列出每一天要做哪部分。
2. 不要抱怨队友（虽然有时候会习惯性地说两句），解决问题才是关键。
3. 跟队友解释清楚问题需要耐心去理解去阐述，等队友解释完，而不是轻易地否定。
4. 不能把时间都花在个项目上，因为这样效率反而更低。脑力劳动者的休息不是去睡觉，而是思考不同领域的问题。所以不要翘课，上课该听讲还是要听。