【Alpha】“北航社团帮”小程序v1.0项目展示

1629866-20190419233842452-1071233970.png

alpha阶段发布声明

1.团队介绍

  • 团队名称:北航红太阳 BuaaRedSun
  • 团队成员介绍:(点击名字跳转至个人博客)
成员角色自我介绍照骗
HansBug架构师,后端组长。做过一些简单的开发,写过一些简单的算法题,喜欢没事写写程序,偶尔去创造一下奇迹改变一下社会。1629866-20190315132422132-1676964678.png
马振亚后端开发擅长各种行政打杂事物(给各位大佬端茶递水)
能写 c/java/python/js
求各位大佬带带
1629866-20190315132433634-552877201.jpg
庄廓然后端开发熟悉java,c++,c,c#,参与过的安卓开发,后台开发,写过unity游戏脚本,工作积极,希望向各位大佬学习。1629866-20190315132507348-413452868.jpg
周雨飞前端开发主要负责的工作是给其他几位大佬端茶递水
擅长Java/Python
前端和后端都会一点点
求各位大佬带飞
1629866-20190315132459387-358760748.jpg
李大前端开发活泼开朗。非计算机/软工学生,16级高工3系,接触过一些简单的软件项目(app、unity游戏),希望在软工课上体验较复杂的软件项目团队开发,积累经验。学习写代码,也学习如何进行团队交涉,和科班同学多多接触,补一补不怎么牢固的cs基础。1629866-20190315132443671-462652464.jpg
廖青城前端开发↑来自生医学院~
但是喜欢写bug然后debug(什么x),希望通过该项目学会如何严谨的写bug~(′゜ω。‵)
1629866-20190421222701903-1173162458.png
彭宇飞需求分析,沟通社联社联主席。经管学院信息管理专业,逻辑思维较强,产品经验比较丰富。做过一些小型的算法和数据库,要积极向组内各位同学学习!
1629866-20190421222714680-403570831.png
谢静芬PM计算机系大三狗
人送外号分解(所以经常在数学课躺枪...)
虽然逻辑严密,擅长写文档(误)
但是算法能力较弱,编程效率较低
希望在团队中向大佬们学习,提升自我~
1629866-20190315132451604-1179824032.jpg

其中,青城和宇飞没有选软件工程课,属于外援~~

2.回答一些工程问题

1.团队项目的目标,预期的功能描述,预期的典型用户,预期的用户数量在哪里?

整个项目的目标和预期功能

在用户群体上,我们加入了社联管理员,现在一共是三个用户群体:普通学生、社团管理员、社联管理员。

我们打算针对不同的用户群体开发出不同的平台和功能:

  1. 普通学生:使用“北航社团”小程序,功能包括:浏览各社团活动和动态,浏览各社团的文字和视频介绍,在线申请加入社团支付社费,报名社团活动,接收社团的活动通知,申请创办新社团。
  2. 社团管理员:使用“北航社团平台”校内网站,功能包括:编辑社团信息,设置入社条件,管理社员,向社联报备活动、申请活动场地,发布投票,发布消息,发布活动、审核报名人员、向报名人员发送活动通知。(多数功能已经由wowotou团队完成)
  3. 社联管理员:使用“北航社团平台”后台可视化数据库/校内网站,功能包括:线上审批各社团的活动申请和场地申请(甚至一键封装成邮件发给团委老师进行线上审批),全周期记录各个社团的信息和发展动态,便于建立覆盖全社团的星级评定体系。

其实还有很多能够挖掘的功能,比如wowotou团队在前期规划了但尚未实现的一些好功能:在线售卖社团文化产品、社团论坛、社团网盘等,我们认为这些功能还需要进行针对性的需求调查。

整个项目的预期典型用户

  • 萌新M
用户信息用户情况
姓名萌新M
用户身份某学院大一新生
用户情况刚入学,对于各个社团的情况不大了解
用户动机希望能方便地查看各个社团的介绍和活动,同时方便地加入自己感兴趣的社团
用户痛点1目前找不到集北航社团咨询与一身的平台。社团的公众号太分散,一个个去关注和查看文章十分麻烦;社联推送的社团介绍也比较有限。
用户痛点2加入社团的步骤比较麻烦,一般需要在百团大战外场中,先填写基本信息问卷,然后支付社费,接着加一位社团管理员为好友,这样才能被拉进群,外场人好多真的好挤。
典型场景1百团大战马上要来了,萌新M想率先了解各个社团的情况,于是打开了“北航社团”小程序,浏览了自己感兴趣的社团类别,以及热度比较高的几个社团的信息。他觉得A社团很符合自己的兴趣,于是直接在线上交了社费并加入了A社团,他被拉进了A社的群里,感受着老社员们对萌新M的热烈欢迎。
典型场景2萌新M看到小程序上对于B社的简介,觉得有点兴趣,但是还不确定要不要加入,于是他去看了B社的百团大战外场,十分喜欢,当场通过小程序一键加入了B社,减去了繁琐的入社步骤,还能跟外场小姐姐多交流一会儿,美滋滋。
使用环境主要是在零散的时间内、在随时可能移动的状态下,去关注社团信息,比如去教室的路上、课间休息时间、食堂排队时间、在宿舍宅着时等。
用户比例40%
重要性★★★★★ 非常重要,如果从大一开始就认可这个小程序,并时常关注北航社团的信息,那么这部分用户的使用年份会很长;另外,如果萌新M之后当了社团管理员,也会向社员推广这个产品。
  • 二狗G
用户信息用户情况
姓名二狗G
用户身份某学院大二学生(本表也适用于大三学生 三狗)
用户情况因为特别喜欢参加A社的社内活动,所以二狗G加入了A社团,积极参加A社每周末定期举办的活动;同时对于其它社团有趣的公开活动也蛮有兴趣。
用户动机希望能方便地参加社内活动,同时希望能获取其它社团的公开活动的信息。
用户痛点1社内活动由于场地等原因,经常会有变化,比如时间、地点的更换,或者本周活动取消,但是由于社团群里聊天消息太多,有时候会错过这样的重要通知信息。
用户痛点2虽然只加入了A社,但是二狗G对于BCD社的公开活动也很有兴趣,但是这些活动只能通过刷朋友圈,或者主动查看公众号文章的方式来获取信息,十分不便。
典型场景1由于场地原因,本周末A社的社内活动取消,社长在群里发了通知,同时也用小程序给社员们发了通知,社员们纷纷议论起来,群里聊天消息达到99+。正忙着敏捷开发的二狗G打开微信群,并不想将聊天记录往上翻,他直接点开了小程序给他推送的服务通知,哦看来这周末的时间可以全部用来敏捷开发了,嗯接着干吧!
典型场景2二狗G觉得自己最近有点宅,想看看有没有什么活动可以参加,他打开“北航社团”小程序,哇塞,B社居然邀请到了知名相声演员郭德纲来讲相声,必须安排!还有10个名额,快抢!10元入场费?值!他心满意足地放下手机,吹起口哨继续debug。
使用环境主要是在零散的时间内、在随时可能移动的状态下,去关注社团信息,比如去教室的路上、课间休息时间、食堂排队时间、在宿舍宅着时等。
用户比例50%
重要性★★★★ 很重要,他们占活动参与人员的很大比例。
  • 社管S:
用户信息用户情况
姓名社管S
用户身份A社的社团管理员,比如社长、部长等
用户情况1.对内,需要向社员发布社内活动消息、统计活动报名人员、通知活动变更情况、统计社员基本信息; 2.对外,需要向大家宣传A社,及A社的公开活动,积极拉人进社,完成信息收集、社费收取等入社步骤; 3.对上,需要向社联报备活动、申请场地、上交社员信息、上交星级评定材料。
用户动机1.希望能方便地管理社员,发布活动、通知、投票等; 2.希望能有好的渠道宣传本社情况,非社员能更方便地入社,也减少社团繁琐的工作; 3.希望能向社联方便地申请场地、报备活动,社联也能保存好各种信息,每年星级评定的材料不用交太多,这样也更公平…
用户痛点1进行社团管理工作时,一般会把通知消息或者报名问卷、信息填写问卷等放到社团的群里,但是这些重要的消息经常被社员的聊天水过去了,需要重发。上述方式不仅麻烦,而且效果不佳。
用户痛点2百团大战时,前来报名入社的人很多,但是由于报名步骤比较繁杂,导致现场比较混乱;而且百团大战之后,基本就没有什么人会加入社团了,社团缺乏一个好地平台展示自己;宣传公开活动时,大多只能通过公众号文章和朋友圈的形式进行宣传,宣传效果不佳。
用户痛点3报备活动、申请场地等流程较为繁杂;而且有时候团委要统计各个社团社员的一些情况,比较麻烦;星级评定时需要提交很多材料,比较麻烦。
典型场景1社团A要给社团内部成员设计一套社服,社管S于是通过“北航社团”网页端编辑了一个投票,并一键推送给了所有社员,社员通过服务通知接收到了该投票进行填写(如果开启了接受社内消息的功能);投票截止后,社管S通过网页端下载到了社员的投票情况,坐等社长夸奖。
典型场景2社团A要举办一个公开活动,社管S于是通过“北航社团”网页端编辑了该活动的基本信息,并一键发布活动(这里也考虑加入社联的审核功能),所有“北航社团”小程序的用户都能在“活动”页面查看该活动的情况,并可以在线报名和支付活动费用。哇塞,这次活动有好多非社内成员参加,给活动部的小姐姐点赞。
使用环境由于需要编辑问卷内容、活动信息等,因此一般在电脑端进行使用。
用户比例7%
重要性★★★★★ 十分重要,如果能让社长体会到本产品对于他们管理社员、宣传活动、对接社联的便利性,他们会更愿意帮助我们在社员中推广此产品。
  • 社联L:
用户信息用户情况
姓名社联L
用户身份归属于社联,负责管理各社团事务
用户情况社团上报的活动需要上交给团委进行审批;需要了解社团的发展情况,并帮助他们发展;需要收集星级评定的资料。
用户动机1.希望活动审批等流程能更加信息化,更加高效; 2.希望能全面了解社团发展情况; 3.希望能方便地管理各个社团的信息,使星级评定更加合理和客观。
用户痛点1采用纸质版的审批流程,流程复杂,跑动量大,自己累,还经常被社团管理员抱怨
用户痛点2想要给社团提供一定的发展支持,但是难以了解社团的情况,无法很好地主动给予帮助支持,只能由社团主动提出自己的需求。
用户痛点3星级评定材料的收集、审核和打分都主要靠人工进行,工作量大,且有失一定的客观性。
典型场景1社管S发来了活动报备表,社联L通过“北航社团”这套信息化的系统,及时接受到活动报备表,初步审核后将活动信息通过邮件转发给指导老师和团委老师,审批的老师一键同意了该活动,社联将审批结果下达给社管S,皆大欢喜。
典型场景2从社团的人数、活动、热度等角度,系统全面地记录了两年来社团A的情况,通过数据来量化社团的整体情况,社联L发现社团A的公众号文章阅读量很低,仔细调查后发现排版不行,于是直接联系社团A宣传部,进行相应的培训;同时还发现社团A的活动经费比较匮乏,社联L主动提出帮该社团联系赞助,真棒!
典型场景3从社团的人数、活动、热度等角度构建了社团评价体系模型,每年星级评价时,这部分指标直接通过系统进行打分;只需向社团收取一小部分其它资料进行人工打分即可;打分完毕后公式结果,大家对于数据都很服气。
使用环境由于需要审核活动信息、看到信息表格等,因此一般在电脑端进行使用。
用户比例3%
重要性★★★★★ 很重要,如果能让社联体会到本产品在管理社团、评价社团、审批活动等方面的便利性,他们可以在社长中大力推广此产品。

整个项目的预期用户数量

  • alpha阶段小程序发布后一周内,用户量累计500人
  • beta阶段小程序发布后一周内,用户累计1000人
  • beta阶段网页端发布后一周内,15位社长和社联进行使用,约20人。
  • gamma阶段网页端发布后一周内,社联和多数社长进行使用,约80人。

2.团队的产品如何满足了用户的需求?要看到目标用户使用产品的过程和评价 (视频或者活人上台介绍)

alpha满足的用户需求

alpha阶段的小程序由于没有社团管理功能,因此主要满足前两类用户的需求,简单来说就是 浏览社团信息 和 浏览活动信息。alpha阶段的具体功能如下:

模块功能
登录授权登录,游客模式,无需填写信息
活动展示首页轮播热度最高的四个活动,查看活动详情,关注和取消关注活动
新闻展示查看新闻简易列表,跳转公众号文章详情,按类别筛选新闻
社团展示搜索社团,按类别展示社团,查看社团简介、新闻、活动等,关注和取消关注社团
“我的”查看自己关注的社团和新闻,查看开发者信息

点击此处跳转发布声明,查看展示软件功能的动图。

3.事先定义的软件下载量达到了么?为什么没有达到?

alpha用户量一览

4.19日18:00小程序通过审核。截至4.23日清晨,共有334名用户使用了我们的小程序。累计用户访问数的变化如下图:

1629866-20190423094638437-90300223.jpg

之前预估的用户量500,指的是是发布后一周内的用户量,按照这个趋势我们认为可以达到目标用户量,因为目前我们还没有私聊社长帮忙推广。

4.团队的成员如何分工协作的?有什么经验教训?

团队分工及经验教训

(一)团队成员总体分工

成员分工协作
少昂经验丰富,为后端组长,负责架构设计、部署、建立用户系统,并指导振亚和廓然进行接口设计和开发,保证接口质量。
振亚、廓然进行数据库初步设计,接口设计和开发,同时负责后端的测试。
雨飞、李大、青城分管不同页面的前端开发;撰写接口设计初步文档,交予后端调整和实现;承担部分UI设计。
宇飞联系社联和社长,并承担部分UI设计
静芬需求分析、 联系社联、原型设计、博客撰写、主持和记录例会、协调前后端、前端测试等

(二)任务细化分配(为初步计划,与实际进度有出入):

1629866-20190404175548223-158320363.png

1629866-20190410122545636-1413283977.png

(三)经验教训:

  1. 后端三人小组内部,由富有经验的少昂进行指导,并把关代码和文档,能够较好地保证后端代码的合理性、数据库的正确性等,但这依赖性较强,还是应该让两位小白早点独当一面。
  2. 前端三人小组内部,由于是按页面分工,需要协调的东西少,而且小程序容易上手,因此前端进行得比较顺利。之后仍会以页面进行分工。
  3. 前后端对接方面,过程是,首先是由前端给出初步的数据请求文档,然后由后端进行调整,并整理成接口文档,再由前端确认无误后,后端再进行接口的实现。这多次握手,虽然表面上能够保证接口设计的正确性,但实际上中间出现了断层:前端人员对需求的理解不够,导致第一步的文档有较大纰漏,同时后端也由于对需求的理解不够,直接根据第一步的文档进行下一步,从而延续了文档的错误,最后出现了经常改动接口文档和代码的现象。教训是,PM要给团队成员讲清楚需求,督促和考察团队成员是否理解了需求,同时要从需求的角度把关接口文档的设计是否正确,在设计正确性得到验证之后,再进行接口实现也不迟。
  4. 整体设计方面,由于少昂在前期失去沟通,因此前期的后端主要由后端两位小白辛苦摸索出来的,而后期他参与进来后发现一些设计不大合理。所得到的教训是,要早点咨询少昂的意见、和他讨论,他的经验比较丰富,能够给出很好的意见。

5.团队是如何进行项目管理的?

团队项目管理

参考课程组给的链接,我们使用github进行项目记录和管理,同时也使用了gitlab。具体的流程是:

  1. 每周开始前,由PM定下前后端在本周的任务和目标,并尽量分配到具体每个人的本周任务,同时声明一些特殊时间节点,比如A同学的B任务必须在周x前完成,因为B任务是另一位同学的前置条件。
  2. 每个人根据自己本周的任务,以及自己本周其它个人事情的安排,列出自己的每日计划,也可以提出对自己的任务进行转移和调整。
  3. 每日计划上传到gitlab公示,由PM初步判定计划可行性,有需要时做出一定的调整。
  4. 每天晚上23:30进行线上会议,每个人汇报今日完成的任务、工作量等,对照看是否完成了自己的计划,如果没有完成如何调整。
  5. 由于课程组要求有燃尽图,因此PM会在每周初将大家的计划转为issue,并每天根据例会上了解到的进度情况更新issue,从而得到每日燃尽图。

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

时间/质量/资源的平衡

主要是通过两个方法来平衡:

  • 每日计划的制定:由团队成员个人来制定自己的每日计划,当然这个计划的周目标是由PM指定的,这个计划接受团队其它成员的监督。这样能让团队成员自由把控时间,这样比PM直接分配每日计划要更方便、更人性化、更有可行性。
  • 软件功能的优先级划分:考虑到alpha版本中队员们需要进行磨合、熟悉工具等,因此能实现的功能有限,必须划分优先级,alpha版本实现优先级最高的功能,并同时根据项目实际进展,来暂时砍掉或加上一些功能。核心功能的质量必须得到保证。

7.在产品之外,团队代码的软件工程质量如何?如何用数据来证明?

参见我们的测试报告

8.测试用例数目,代码覆盖率数目。

9.运行测试用例得到代码覆盖率的视频录像,(需要现场看到。 没有诸如 “我的电脑没有装测试环境”,“文件不全”等等借口)

测试用例和代码覆盖率

  • 测试用例数目:50,代码覆盖率:controllers为93%, models为91%。
  • 视频录像:暂时用U盘查看

10.代码规范在哪里?

11.齐全的文档在哪里?

14.明年的同学继续开发这个项目,会不会出现类似的抱怨?如果一个新学生在一台新机器上想编译并运行你的项目, 请问能顺利完成么?有什么样的文档能指导新学生?

文档位置和新人入口

12.有些项目是在原来的基础上改进的,那么我们团队的软件工程项目质量有什么样的提高?例如,代码覆盖率从原来的x增长到y?

13.原来的项目有些代码混乱,没有注释,没有详细的文档,你们的项目是如何更好解决这个问题的?

关于以前的项目

  • 答1:虽然我们的项目在名义上,是基于以前的项目,但其实两个项目只是有所交叉,其实区别很大,而且以前项目的版本太旧跑不起来,因此我们决定在Alpha阶段暂不使用以前项目的代码。
  • 答2:鉴于两个项目只是有所交叉,其实区别很大,而且以前项目的版本太旧跑不起来,因此我们在Alpha阶段暂不使用以前项目的代码。

15.对于项目的目标用户是一般学生的项目, 你们如何找到学生做需求分析?他们给你什么样的反馈?

整体项目的需求分析

用户需求的调查分为两个部分:

(一)需求调查第一部分:向学生发放问卷调查。

1.发放位置:几个社团内部微信群、去年的体育类社长群、朋友圈。(以此保证参与问卷的人的院系比例、年级比例较为合理)

2.参与问卷调查的人员共126人,人员比例比较合理:有几乎一半人是大一大二的学生,他们有的刚入校园,对社团不甚了解,有的正处于参加社团的活跃阶段。另一半人多为大三学生,他们经历过了参加社团的活跃阶段和冷却阶段,对社团的体验和感受更深刻。

1629866-20190320225022897-1159187106.png

3.调查结果:

(1)在126个学生中:

项目内容
痛点1.约81%的人认为,他们刚入北航时缺乏一个渠道来了解各个社团,其中有近一半希望有个平台能整合一下各个社团的介绍,并进行分类。
2.约89%的人希望在百团大战过后仍能方便地了解各个社团的活动,其中约一半的人认为目前只能通过朋友圈和公众号了解,比较麻烦。
3.约90%的人认为,在他们参加社团活动时,经常需要填写报名信息,这十分不方便。其中有近50%的人认为,每次要填的信息都差不多,令人烦躁;有约20%的人认为,报名问卷容易被社员的聊天水过去;有约31%的人希望能有个小程序帮助他一键报名
4.令我们惊讶的是,约65%的人表示,他们曾经错过了自己很想参加的社团活动!
需求1.能方便地查看各个社团的文字和视频介绍,以选择自己想要加入的社团并在线申请加入。
2.即使没有加入某个社团,也希望能方便地浏览各个社团或自己感兴趣的社团的活动和动态。
3.能够及时看到活动通知并一键报名,防止错过自己想参加的活动。
需求类型辅助性需求
需求量估计调查显示,有约93%的人表示愿意使用我们的小程序,且由于小程序易于传播、用户群体扎堆等优势,如果用户对产品比较满意,可能比较愿意向他人推荐。

(2)由于我们第一版重点在于开发小程序,因此决定后两个版本再由社联协助、覆盖性地调查各个社长的需求。因此本次调查中,我们仅初步调查了一些社长的意愿,在126个学生中有16个社长:100%的社长表示愿意使用我们的产品,用来进行社团管理、活动发布、社团宣传甚至获得赞助等。

(3)附调查问卷的部分结果截图:

1629866-20190320230204558-280764553.png

1629866-20190320230145036-1729242566.png

1629866-20190320230100468-2080022277.png

1629866-20190320230119139-2112285025.png

(二)需求调查第二部分:对社联办公室和宣传部的代表人员进行了电话和微信采访。

(1)社联办公室的人表示,对我们产品的十分认可,能够提供产品推广、数据收集等的帮助:

这可是个好东西,社联办公室主要负责的是社联与社团的对接与沟通,是可以直接联系到各个社团的,如果有什么需要帮忙的可以来找我们。

(2)社联宣传部的人表示,我们的观点与他们十分吻合,他们能够提供一定的UI支持。

事实上很巧,我们也正在筹备小程序的事情。目前做了一点点UI,但是因为没有需求分析和交互逻辑,所以还在设计主视觉形象,其实并没有什么进度。我正在向部长团征集想法,等征集好了一起发过去。我们这边有新媒体的童鞋能提供UI支持。我们希望社长能在上面申请活动场地,我们能在线审核。而且我们打算一直使用这个产品,但是又不懂运维,希望你们能提供一个后台数据库的非技术型、可视化界面,便于我们进行长久的管理。

用户反馈

  1. 整个项目的计划和设计阶段时,通过绘制原型系统,我们招募了12名社联成员进行认真的体验和反馈,最终我们整理出了用户对于原型系统的反馈表格
  2. alpha版本推广过程中,有一些同学提出小程序中的数据比较少,包括社团和活动的数据。目前我们的系统中有4个未过期活动,1个已过期活动,29篇微信公众号文章,还有18个社团,多数为手动摘取和录入,我们会尽快实现一个能够让社长增改数据库部分内容的接口。
  3. alpha版本推广过程中,我们也发放了问卷,但是填写人数较少,填写质量较低。考虑到之前已经有对整体项目的需求问卷,以及社联人员对原型系统的反馈表格,因此这次的用户反馈问卷让用户感觉比较疲惫。前两次调研,已经足够我们进行下一阶段的设计。

16.所有的项目都会收集到用户的数据,请问你们对这类数据做了什么样的分析,这些分析如何验证或推翻了原来的假设?这些数据如何帮助项目改进软件工程的质量?

小程序用户数据分析

微信公众平台自动收集了用户数据。主要分析以下数据项:

  1. 四天来,每天的累计访问人数:

    1629866-20190423094638437-90300223.jpg

  2. 四天来,以半小时为粒度的实时访问次数:

    1629866-20190423094729504-1547338104.png

  3. 四天来的访问分布,包括访问来源、访问时长、访问深度 三个方面:

    1629866-20190423094802804-38314237.png

3.项目情况

进展-燃尽图

  • alpha-1(至4.9日):

1629866-20190409151251709-374522323.png

  • alpha-2(至4.14日):

1629866-20190414080840939-1491415795.png

说明在项目管理中,scrum的燃尽图是如何真实反映项目的状态的?或者燃尽图美化了状态?

答:由于无法细致地制定1-2周后的任务,因此我们将alpha阶段分成两个小段,每个小段开始时,详细定制本段计划,转为issue,这便是燃尽图中第一天的起点高度(虽然在这一小段中,我们可能会根据实际情况添加或删除issue,但issue总量变化不大)。每次例会上每个人总结自己的今日进度,由PM统一更新issue状态,以防止团队成员忘记更新issue。

发布的功能

参见发布文档,简表如下:

模块功能
登录授权登录,游客模式,无需填写信息
活动展示首页轮播热度最高的四个活动,查看活动详情,关注和取消关注活动
新闻展示查看新闻简易列表,跳转公众号文章详情,按类别筛选新闻
社团展示搜索社团,按类别展示社团,查看社团简介、新闻、活动等,关注和取消关注社团
“我的”查看自己关注的社团和新闻,查看开发者信息
  • 最有特色的功能:将社团最近的公众号文章集成到本小程序中,用户无需关注公众号、还可方便地查看和筛选各社团的文章。

软件发布地

小程序发布在微信平台上,有两种获取方式:

  1. 打开 微信-->发现-->搜一搜-->输入“北航社团帮”,即可搜索到我们的小程序。
  2. 打开 微信-->扫一扫,扫描下方小程序码,即可进入我们的小程序:

img

用户反馈截屏

  • 用户直接在推广处评价:

    1629866-20190422204512043-1250276584.png

  • 用户通过问卷反馈,这里显示部分反馈结果:

1629866-20190422221813304-398444929.png

1629866-20190422221734140-1109670574.png

  • 用户对于原型系统的反馈(部分展示):

1629866-20190422222049444-306118441.png

  • 发布后发现的bug:
    • 微信名含有非法字符(如表情)时,登录错误,已修正。
    • 社团-->活动-->活动详情,显示错误,下一次发布修正。

4.团队成员角色和贡献

  • 团队成员alpha阶段最终贡献分:(贡献分和为 50*8=400)
名字角色团队贡献分具体量化的贡献
少昂后端开发503351行代码,179行文档,1篇技术规格博客
振亚后端开发、后端测试72930行代码,170行文档
廓然后端开发、后端测试64641行代码,172行文档
雨飞前端开发502500行代码,20行注释,50行文档,1篇技术规格博客
李大前端开发421000行代码,250行文档
青城前端开发496000行代码,50行注释,50行文档
宇飞需求分析和UI设计11整理一次用户原型反馈,logo设计
静芬PM、前端测试6218篇博客,4次推广,2次用户调查
  • 去掉外援后,成员得分:
名字角色团队贡献分
少昂后端开发45
振亚后端开发 、后端测试63
廓然后端开发、后端测试56
雨飞前端开发44
李大前端开发38
静芬PM、前端测试54
  • 贡献分细则:

1629866-20190423102934800-1817263430.png

5.总结和展望

  • 学到的东西:
    • 技术上更加成熟和规范。
    • 互相磨合,对团队合作有了更深入的理解,能够互相理解和包容。
  • 对课程的建议:
    • 希望在博客作业要求中说明时间节点等重要信息。
  • beta阶段初步计划:
    • 完善小程序的UI
    • 小程序中加入社团管理功能
    • 开发网页端进行社团管理,与小程序互通,争取在10个社团中达到实用效果。

转载于:https://www.cnblogs.com/buaareadsun/p/10747444.html

  • 0
    点赞
  • 0
    评论
  • 4
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
©️2021 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值