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个