【Beta】Scrum Meeting 7 & 与助教谈话

前言

Beta阶段第7次会议在5月12日22:00由PM在大运村一公寓三层召开, 时长30min。

任务分配

姓名	今日任务	明日任务	困难
周博闻	修复修改密码问题#54 添加主页公告栏 #57（调整样式）	修复修改密码问题#54
周国杰	控制台接口单元测试#51	2200116 数据处理脚本#59
樊子康	markdown后端路由及控制器#38 markdown后端处理脚本#39	markdown前端用户选择界面#40
殷刘霄羽	2200116实验模板 #60	D01实验内容梳理 #61
何雨峰	2200116实验模板 #60	D01实验内容梳理 #61
王尖兵	移动端报告页 - 收藏夹#46	移动端报告页 - 收藏夹#46
杨帅	控制台接口单元测试#51	控制台接口单元测试#51

燃尽图

会议照片

代码签入记录

项目困难

修改密码的问题仍然没有找到具体缘由，考虑暂时搁置。

与助教谈话（5.11）

关于交付件的验收标准

"但某些后端的任务没有定义可衡量的交付内容，基本都是经过：人工验证该接口/后端模块功能实现了，就算是交付了"
若是人工验证的话，能否给出验证的流程？好比某个功能执行了某个操做，给出了怎样的预期输出

咱们认为这个比较靠谱，将在任务完成的差很少时补全一下这部分任务的验收工做。
能够考虑后端尽可能使用单元测试进行验收，而前端能够进行功能方面的验收。

注：在写了一些测试后咱们发现，对于后端一些难以用单元测试验证的功能，在不复杂的状况下仍须要采用人工测试的方式，例如上个阶段中关于上传实验报告的部分，目前并无找到比人工测试更好的办法……

关于下降脚本开发门槛

这个部分原先是PM在Alpha阶段收尾时开的一个脑洞，即作成拖拽式的脚本编写，但团队成员包括PM本身都认为这个短期内作不完（甚至能够单开一个软工项目）因此目前搁置了。

原来是这样，建议博客补全

不过咱们认为本阶段的markdown功能对于实验模板编写门槛的下降是起到了必定做用的，但python脚本这里目前没有好的解决办法。

关于新成员工做

@新成员 我看你已经作了一个页面设计，还有重构，正在添加主页公告栏。新技术上手了吗？

逐渐上手了。

你和另外一个同窗都作了 #42 #43 #57三个任务，讲讲通过？好比是均分任务仍是结对编程？

PM：感受都有，好比主页这边改的时候基本是A改而后B来作复审以及提供一些意见。而后主页公告栏这里就有点均分任务的意思，A加好html部分而后B调样式。

新同窗开发有什么困难吗？

困难固然就是要适应这个项目的框架。实际上前段改的的东西也不算太多，主要是处理一些细节，要把这个项目的前段所有阅读一遍而后改。

除此以外困难也出如今熟悉开发流程方面，咱们靠qq远程桌面交流并解决了一些操做问题。

这个时候就能够进行结对编程了。

关于规范commit记录

感受大家的commit能够规范一下。简单能够，但风格有不少种不太行。以及像有多个commit处理一个功能的状况，可使用 git rebase -i 合并多个commit

咱们能够在以后统一一下commit的格式，好比统一使用动名词组的形式。对于一些注释性的内容能够放在comment里。
（不知道comment是一个github的功能仍是git自己自带的功能，还须要继续研究）

关于单元测试

我看大家以前提到了要搞单元测试，讲讲单元测试方面的进展？

如今单元测试写了一半了，感受开好头以后就要轻松一些，主要是很差上手。

有留文档吗？好比测试计划、进度之类的。

没有，这部分就是开会的时候讨论汇报的。

下一届的人接手项目以后怎么上手单元测试之类的东西有考虑过吗？

这部分咱们计划出一篇技术博客的，关于单元测试方面，但如今坑尚未踩完。（还在坑里没彻底爬出来

预计单元测试还要作多久？

这个得看最终计划覆盖多少代码吧，控制台部分应该明后天能够所有覆盖测试完成。

“假如项目一开始就有详尽的单元测试，对于以后接手的同窗也比较友好。” 我以为大家可能须要多写一点注释和文档来体现这个友好。

引伸：关于Gamma计划的讨论

（接以上的话）

咱们最近讨论了一下Gamma阶段的任务，由于感受其实这个网站功能也就目前这样了，因此在考虑下个阶段主要目标是提高一下工程的质量，包括文档、注释还有代码规范啥的。以及一些编码很差的地方修改，好比以前在代码里写死了不少配置方面的内容。

我以为若是大家把完善项目做为目标的话，要设计好怎么检验，最终怎么评判。

这个咱们也有所考虑，主要是须要从好比 注释量 这种指标以及与以前文档的对比方面来考虑。以及一些统一的配置文件和使用说明等等。

感受这部分是若是结果不是很清晰，很容易给人一种在划水的感受。

是的。