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

alpha阶段发布声明

1.团队介绍

• 团队名称：北航红太阳 BuaaRedSun
• 团队成员介绍：（点击名字跳转至个人博客）

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

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

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名用户使用了我们的小程序。累计用户访问数的变化如下图：

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

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

团队分工及经验教训

（一）团队成员总体分工

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

（二）任务细化分配（为初步计划，与实际进度有出入）：

（三）经验教训：

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

文档位置和新人入口

• 文档在gitlab上，主要包括：
  • 前端请求的数据初步文档
  • 后端持续更新的接口文档
  • 每日计划文档
  • 代码规范
  • 快速搭建环境文档
• 明年的同学若继续开发这个项目，可能会有一些抱怨，但是怨气不会太大。因为我们的文档还算完备（如上），能够让新学生了解整个项目从0到1的过程，以及最重要的接口文档。其中，上述快速搭建环境文档可以指导新人顺利运行我们的项目。

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

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

关于以前的项目

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

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

整体项目的需求分析

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

（一）需求调查第一部分：向学生发放问卷调查。

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

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

3.调查结果：

（1）在126个学生中：

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

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

（3）附调查问卷的部分结果截图：

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

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

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

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

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

用户反馈

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

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

小程序用户数据分析

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

1. 四天来，每天的累计访问人数：

   

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

   

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

   

3.项目情况

进展-燃尽图

• alpha-1（至4.9日）：

• alpha-2（至4.14日）：

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

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

发布的功能

参见发布文档，简表如下：

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

• 最有特色的功能：将社团最近的公众号文章集成到本小程序中，用户无需关注公众号、还可方便地查看和筛选各社团的文章。

软件发布地

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

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

用户反馈截屏

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

  

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

• 用户对于原型系统的反馈（部分展示）：

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

4.团队成员角色和贡献

• 团队成员alpha阶段最终贡献分：（贡献分和为 50*8=400）

名字	角色	团队贡献分	具体量化的贡献
少昂	后端开发	50	3351行代码，179行文档，1篇技术规格博客
振亚	后端开发、后端测试	72	930行代码，170行文档
廓然	后端开发、后端测试	64	641行代码，172行文档
雨飞	前端开发	50	2500行代码，20行注释，50行文档，1篇技术规格博客
李大	前端开发	42	1000行代码，250行文档
青城	前端开发	49	6000行代码，50行注释，50行文档
宇飞	需求分析和UI设计	11	整理一次用户原型反馈，logo设计
静芬	PM、前端测试	62	18篇博客，4次推广，2次用户调查

• 去掉外援后，成员得分：

名字	角色	团队贡献分
少昂	后端开发	45
振亚	后端开发 、后端测试	63
廓然	后端开发、后端测试	56
雨飞	前端开发	44
李大	前端开发	38
静芬	PM、前端测试	54

• 贡献分细则：

• 这里是贡献分规则

5.总结和展望

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

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