【Beta】Daily Scrum Meeting总结

时间:2021-11-01 16:32:04

团队博客目录:FTD团队博客目录

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

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

待解决的问题:

  1. 导出Excel时,我们是直接放一个只有这三行数据的xls文件在raw文件夹里面,然后复制这张表并填充数据。这样前三行是跟导入的表一致的(如果一学年只有上下两个学期的话)。这可能与老师的要求不符,因此需要将其更换为从数据库中取出。

  2. 当只有一个任务时,删掉该任务,任务列表会保留这个任务,点进去程序会崩溃。

  3. 到了截止时间后,不能操作。这个功能还未实现。

  4. 删除教师时,列表没有更新。

  5. 发布报课任务后,教学办无法修改任务信息(如截止日期)。


二、过程体会

  • 先附上燃尽图(本来想从第七天冲刺里直接拿出来的,结果发现没有燃尽图!吓得我赶紧补上)
    【Beta】Daily Scrum Meeting总结

  • 整个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完成。很幸运能与你们组队。


三、组员分工及工作比例

团队统计

版本 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%

四、合照

我们队目前只有三个成员获得了黄衬衫,暂时从别人那借了一件 _(:з」∠)_

【Beta】Daily Scrum Meeting总结

可以对比我们第一次团队展示
【Beta】Daily Scrum Meeting总结

【Beta】Daily Scrum Meeting总结

【Beta】Daily Scrum Meeting总结

【Beta】Daily Scrum Meeting总结

【Beta】Daily Scrum Meeting总结