Gamma阶段项目展示

Gamma阶段项目展示

一、 团队成员介绍

姓名	Gamma职责	个人博客
张圆宁	PM，后端	个人博客
王文珺	后端	个人博客
牛宇航	后端	个人博客
申化文	后端	个人博客
汪慕澜	测试，部署	个人博客
陈致远	前端	个人博客
李青阳	测试	个人博客

二、 关于公课网项目

• 团队项目的目标，预期的典型用户，预期的功能描述，预期的用户数量在哪里？

  • Gamma阶段团队项目的目标：优化用户体验，增加相应功能。

  • 团队项目的总目标：实现一个以课程评价和查看为主要功能的网站。

  • 预期典型用户：北航本科生。

  • Gamma预期功能描述：

    • 优化用户体验

    • 增加找回密码功能
    • 增加管理员和信箱相关功能

    • 实现HTTPS。

  • 总功能描述：

    • 注册登录
    • 找回密码
    • 修改个人信息
    • 评价课程
    • 查看课程
    • 删除评价
    • 推荐课程
    • 管理评价

  • 预期用户数量：200人。

• 团队的产品如何满足了用户的需求？要看到目标用户使用产品的过程和评价 。

  • 我们在主页下留下了github issue链接，用户可以针对遇到的问题进行评价。

  

  

  • 对于满足用户需求的情况，用户会正常使用网站并留下对课程的评论。

• 事先定义的软件下载量达到了么？为什么没有达到？

  • 暂时没有达到。在项目开始时我们预计总使用量为200人。在alpha阶段结束后，用户数为55人，beta和gamma总用户数为42人。三阶段合计为97人，没有达到目标。
  • 原因是多样的。首先由于有两个组做同样的课程评价网站，用户一定程度上被分流。其次我们的推广无法像app一样可以登录应用市场，只能通过发动身边人进行试用，导致了推广效果一般。另外目前还未到同学们结束课程和选课的时间段，网站无法发挥出自身的作用。

• Gamma阶段团队的成员如何分工协作的？有什么经验教训？

  • 分工
    • 每周一集体会议+每日大运村宿舍会议+线上交流。
    • PM张圆宁根据任务实际内容和人员职责进行任务的分配和进度规划，并适度调整分工。
    • 陈致远主要负责前端开发，并完成相应文档。
    • 牛宇航、王文珺、申化文、张圆宁进行后端相关开发，并完成相应文档。
    • 汪慕澜进行服务器端的部署工作，包括https等功能的实现。
    • 李青阳进行测试相关的工作，及时反馈bug和用户体验不佳的地方。
  • 经验教训
    • 由于每周任务的类型不同，需要适时调整人员职责，如在前端没有开发任务时，可以去填补修复bug人员不足的欠缺。
    • 对于https这样的长线任务，要及时规划。我们在beta的最后阶段就了解了https实现的周期可能会较长，gamma阶段安排专人去实现。

• 团队是如何进行项目管理的？

  • 对于前端、后端、测试、部署，留有相应的文档，及时更新，供下一届快速熟悉项目。

  • 代码提交采用git-flow分支管理，具体要求可以参考【技术博客】Git Flow模型管理代码版本。

  • 任务管理，通过github issue进行任务分配及相关细节的交流。

    

• 团队如何平衡 时间/质量/资源 争取如期完成任务的？

  • 时间：团队每周一例会时布置任务，任务周期一般为一周。当周有考试则可以作为正当理由延期，否则下周一前必须完成。
  • 质量：前后端对接会互审代码质量，测试人员对代码进行测试时也会进行审核，保证正确性。出现问题时，由完成本段代码的人进行修复。
  • 资源：在布置任务时，平衡需要修改的代码，尽量不包含冲突。当出现一位开发者需要首先得到另一位开发者的代码时，提前规划ddl，保证互相不影响开发进度。

• 在产品之外，团队代码的软件工程质量如何？如何用数据来证明？

  • 12篇文档从分支管理到测试计划，严格控制开发过程
  • 28个测试用例从功能到用户体验全方位测试
  • 0.24s的搜索响应时间，用户体验极佳
  • 保证2-3天的缓冲期，在确保功能完成的情况下集中修复bug并完善文档。

• 测试用例数目

  • 测试计划：Alpha阶段780字，Gamma阶段180字
  • 测试用例：URL访问14个，用户注册7个，场景测试7个；共28个
  • 发现bug 13个
  • 督促修复bug 10个

• 代码规范在哪里？

  • 我们约定代码规范采用google python代码规范
  • 函数名使用lower_with_under()
  • 变量名使用lower_with_under
  • 对于网页来说，主要是进行各资源的分离，.html/.js/.css/.py/.....

• 齐全的文档在哪里？

  • 前端文档
  • 后端文档
  • 部署文档
  • 测试文档

• 有些项目是在原来的基础上改进的，那么我们团队的软件工程项目质量有什么样的提高？

  • 不谈功能，只谈代码质量。我们在如下方面提升了代码质量：

    • 原先代码中的冗余js代码，去除了登录注册部分的重复代码。

    • 对html增加导航栏，去除其他页面中的导航栏部分代码。

    • 增加文档和注释，方便下一届快速上手。

    • 增加自动化测试代码。

• 原来的项目有些代码混乱，没有注释，没有详细的文档，你们的项目是如何更好解决这个问题的？明年的同学继续开发这个项目，会不会出现类似的抱怨？如果一个新学生在一台新机器上想编译并运行你的项目， 请问能顺利完成么？有什么样的文档能指导新学生？

  • 我们对于后端代码增加了注释，并对前端、后端、测试、部署分别增加了文档。下一届不会出现这样的问题。
• 对于项目的目标用户是一般学生的项目， 你们如何找到学生做需求分析？他们给你什么样的反馈？
  • 我们的公课网站本身就是面向本科生，我们的组会就是第一次需求分析的来源。但一次组会无法想到所有情况，在之后的beta、gamma阶段，我们根据github issues的反馈（如功能欠缺，存在bug等），陆续加上了新功能。
• 所有的项目都会收集到用户的数据，请问你们对这类数据做了什么样的分析，这些分析如何验证或推翻了原来的假设？这些数据如何帮助项目改进软件工程的质量？
  • 我们发现，由于课程排名的存在，大家往往倾向于对已经有一定分数的课程进行评价。这也导致了我们的数据中长尾效应比较严重，有大量课程没有得到评价。我们可以考虑推荐一些没有人评价过的课程给用户，来平衡课程的被评论数。

三、 团队项目的实际进展（拷贝那些 scrum 过程中的燃尽图即可），发布的功能（拷贝发布文档），在哪里发布了软件（3 – 10 个网址）， 用户反馈的截屏。说明在项目管理中，scrum的燃尽图是如何真实反映项目的状态的？或者燃尽图美化了状态？

发布说明

我们gamma阶段的燃尽图可以很真实地反映我们项目的状态。首先在gamma开始的阶段，大家均进入烤漆，考试，期末大作业较多，进度较为延后，之后几天加紧时间赶上进度，在最后阶段都是持续性的测试，优化用户体验等等工作，直到gamma阶段结束才关闭本任务。

四、 团队成员在Gamma阶段的角色和具体贡献

延续Alpha阶段规则，以工作量*难度*完成度为基本原则。具体细则可以参考Alpha阶段项目展示

任务	工作量	难度	完成度	贡献分	得分者	完成任务人数	任务分	备注/描述
网站使用https	4	5	3	60	wml	1	50	承接beta阶段工作，完成剩余部分，时间跨度较大，-10
修改数据库中教师名重复问题	3	3	5	45	nyh、wwj	2	45	合作，个人得分=任务分/完成任务人数
重置密码的后端逻辑	3	4	5	60	nyh	1	60
服务器部署技术博客	2	2	5	20	wml、nyh	2	20	合作，个人得分=任务分/完成任务人数
Xshell登陆远程报错	1	4	5	20	nyh、wwj、wml	3	20	合作，个人得分=任务分/完成任务人数
忘记密码页面	3	2	5	30	czy	1	30
重置密码页面	4	3	5	60	czy	1	50	未完成js页面，-10
头像图片剪裁	4	4	5	80	wwj	1	80
头像文件类型限制	3	3	5	45	shw	1	45
测试计划	4	4	5	80	lqy	1	80
测试	5	5	5	125	lqy、wml	2	125	合作，个人得分=任务分/完成任务人数
管理员后端	3	4	5	60	nyh	1	60
删除自己评论	2	3	5	30	zyn	1	30
消息系统前端	3	3	5	45	wwj	1	45
消息系统后端	5	4	5	100	shw	1	100
管理员页面	4	3	5	60	czy	1	60
https技术博客	2	2	5	20	wml	1	20
gamma修复bug	1	2	5	20	zyn	1	10*2=20
scrum meeting*10	/	/	/	100	zyn	1	100

总分	1040	个人总分/总分*350
wwj	154.1666667	51.88301282
czy	140	47.11538462
wml	149.1666667	50.20032051
lqy	142.5	47.95673077
shw	145	48.79807692
zyn	150	50.48076923
nyh	159.1666667	53.56570513

五、 所做软件最有特色的功能是什么，请着重介绍一下。活的用户如何从你的软件中获益的，请现场展示。

• 匿名发布评论。对于评价类的网站，最害怕的就是言路阻塞。我们采用匿名的方式使得大家都可以开怀畅谈，作出最真实有用的评价。
• 管理员角色的加入。允许匿名发布言论也不代表任何言论都可以通过我们的平台传播（互联网从来不是法外之地），因此大家的评论需要管理员介入管控。
• 消息系统。如若您的评论被删除会收到管理员的来信。
• 教师页面。我们不仅有个人主页还有教师页面，基本实现了想点哪里点哪里的良好用户体验。

六、 团队从用户那里得到了什么反馈，有什么样的bug？这是预料之中的还是没想到的？

• 用户反馈1：希望在搜索结果页增加一个搜索框。

  预料之中，已修改

• 用户反馈2：建议规定在未登录状态下，不能点击“撰写评价”按钮。

  预料之中，已修改

• 用户反馈3：建议修改现有课程搜索后端逻辑，使返回结果的速度更快。

  意料之外，已修改

• 用户反馈4：希望增加找回密码的功能

  意料之外，已修改

• 用户反馈5：希望修改首页搜索功能的前端

  预料之中，已作出部分修改

• 用户反馈6：移动端显示的体验不好，个别表项被压缩导致没法看清

  预料之中，未修改

• 用户反馈7：课程页面的部分文字建议加粗或高亮

  意料之外，未修改

• 用户反馈8：希望增加定制课表功能

  预料之中，未修改

七、 总结，整个团队在Gamma阶段学到了什么，对软件工程的教育，对这个具体的课程有什么批评建议

大家在gamma阶段，由于正好是计算机学院的烤漆，进度推迟了一周。在发布ddl前几天，开始猛赶进度，才勉强完成功能。作为PM，应该事前考虑到这一点，调整任务进度。

对整个课程组来说，相比其他班级，任老师和罗老师班是开始最早，结束最晚的。在我们看来，这两个班的成员理应得到更多的分数（据说我们beta时候其他班在做需求分析，我们gamma开始时其他班就展示完了……工作量总计三周）。但仍然感谢任老师给我们机会去体会团队开发。

八、数据汇总

统计数据

项目	数量
总用户数	97
总登录次数	271
总页面数	9
文档数	12
项目总代码量（不含js和框架代码）	20820行
issue量	108
commit次数	405
正式版本	22
技术博客	4篇

测试人员工作

阶段	发现的功能性bug	发现的用户体验问题
Alpha	3	4
Beta	9	1
Gamma	2	4

此处的bug数量仅包含测试人员测试的结果，不包括用户反馈和开发人员自己发现的bug。

测试计划：Alpha阶段780字，Gamma阶段180字
测试用例：URL访问14个，用户注册7个，场景测试7个；共28个
发现bug 13个
督促修复bug 10个

九、现场展示ppt