Alpha 阶段项目复审
目的
每个复审人看本班级其余团队发布的项目，以及代码质量，实际测试结果， 决定名次，说明项目的优点和缺点分析。
复审
| 序号 | 小组的名字和链接 | 优点 | 缺点和bug报告 | 名次 |
|---|---|---|---|---|
| 1 | 这次稳了队 https://www.cnblogs.com/1430559825qqcom/p/11991467.html | 1.提供方便简洁的登录界面 2.用户容易上手 3.系统完成度高 | 1.手机验证码有时收不到 2.页面侧边栏切换刷新后，侧边栏选中样式默认渲染第一个 3.用户头像信息首次加载不出，活动管理模块搜索结果不全 | 1 |
| 2 | crtl冲锋队 https://www.cnblogs.com/littlehui3/p/11992167.html | 1.基本游戏框架完成 2.界面简洁 3.操作简单魔性 | 1.整体过于简单 2.没有实现联网互战功能，目前还是单机 3.游戏过程无波澜起伏，难度没有逐步提升 4.功能还不够完善，设计感不够强烈。 | 9 |
| 3 | six gods https://www.cnblogs.com/Lin-J/p/11993012.html | 1.提供方便快捷明确的注册与登录界面 2.界面整洁给人焕然一新的感觉 3.简单、易上手，能让用户更容易地使用。 | 1、没有多组商品连续输入的方便操作，只能输入一个商品后再点输入，如果在新建商品多一个按钮“新建下一个商品”来继续输入就比较方便。另外 商品管理系统应该是扫描或者更方便的操作，货量多货量大的时候手动输入不太实际。2、程序的bug：前端bug：对后台返回的JSON错误解析、对可能抛出错误的语句没有用try{...}catch(...){...}语句包围；后台bug：Controller层Bug、session获取错误、未对第三方包生成的JSON进行检查，导致向前端返回了错误的JSON；Service层Bug：未对Controller层传递过来的值为null的参数进行检查，导致抛出NullPointerException；DAO层Bug：一些不可以被认为是bug的bug。未修复bug：Controller层的未对第三方包生成的JSON检查的bug。 3、实现了用户登录、用户注册和基础货物管理功能 4、代码管理使用了码云。https://gitee.com/SixGodsGroup/GoodsManager | 7 |
| 4 | Pineapple-beer https://www.cnblogs.com/Kestrel/p/11992907.html | 播放器的播放界面背景很新颖很独特让人，如果是一部动画片在播放那么会更加吸引人 | 1.播放条比较粗略。2.测试阶段的登录界面缺少美观。3.燃尽图只有前三天的图，但是反映了真实情况。4.Bug暂时也不清楚。5.源代码管理：https://github.com/Pineapple-beer/Teamwork，但是找不到具体代码，应该是还没上传。 | 12 |
| 5 | BLACK PANDA https://www.cnblogs.com/ZWJCNBLOG/p/11992615.html | 1.提供方便快捷明确的注册与登录界面；2.界面纯净简洁；3.简单、易上手，能让用户更容易地使用。4.源代码中有较多注释，方便阅读与修改。5.基本功能实现：注册登录、查找查看博客、编写发布博客。6.分类也做得明确清晰。 | 1、 bug报告：图片上传，文件过大会出错；2.用户可访问不具权限的URL；3.空字段导致异常；4.serializable反序列化时版本不一致；5.图片显示，排版有时会乱；6.较大尺寸的图片上传，导致浏览样式异常。Bug均已解决。 | 5 |
| 6 | 开心超人 https://www.cnblogs.com/dcLeung/p/11992787.html | 1.提供方便快捷明确的注册与登录界面；2.界面整洁给人焕然一新的感觉；3.简单、易上手，能让用户更容易地使用软件 | 1.代码在不同机器上面运行会因为数据库版本的不同而报不同的错误，不同运行环境下如果不能运行，对软件影响很大。2.添加会员会失败，功能未完成，会影响使用。UI不够美观，用户体验还可以加强 3.没有实现货物信息的删除功能 | 8 |
| 7 | 起什么名好啊 https://www.cnblogs.com/zjh20/p/11992595.html | 1.商品信息直观2.操作简单，方便上手 3.数据可视化，方便后期对销售总结 4.有搜索功能 | 1.界面构建在不同分辨率下位置错位，不同分辨率导致界面不一样。2.Ui过于简洁单调，不够美观，让用户使用起来会有不适 3.测试数据量不足，数据量少使得一部分问题未暴露 4.可登录用户人数有限，无法考虑到同时多人登入情况。 | 10 |
| 8 | 量子波动打码队 https://www.cnblogs.com/Lin-J/p/11734033.html | 1. 操作界面简单，通俗易懂 2. 有数据分类功能，即筛选功能 3.有搜索功能 | 1. 可能环境配置要求高，不支持向旧手机客户端兼容；2. 主界面的滑动状态栏目前只是简单的图片滑滑动,点击后没有响应事件；3. 搜素算法的复杂度比较大，效率有待优化；4. 输入法编写失物招领信息时文本信息不能存入数据库（已修复） | 6 |
| 9 | 水桶大队 https://www.cnblogs.com/GNIT/p/11992900.html | 1. 功能齐全，包括添加、查看全部、确认、定时等 2. 界面美观，UI图标比较齐全和漂亮 3.用户反馈比较友好（蜕变记录） | 1. 比较个性化的“自定义习惯”功能还未实现 2. 对于少部分手机，数据统计柱形图只显示6个自变量 3.删除习惯功能有待修复 4. 缺少多用户持续体验测试报告，更多为功能上的单独测试 | 3 |
| 10 | 六姑娘 https://www.cnblogs.com/liujiamei/p/11992659.html | 1. 甘特图表示清晰，清晰体现前后期的合作与分工 2.有代码签入记录截图，进度质量可靠 3. 前后端结合工作完成得不错 | 1.Ui过于简洁单调，不够美观，数据显示地有点硬核 2. 目标广场用户头像无法显示有待后续解决 3. 解决困难的过程没有详细记录 4. 对于git合作开发的操作还不是很熟练，出现部分成员出现代码被吞并的情况（已解决） | 2 |
| 11 | 螺旋升天队 https://www.cnblogs.com/nullcjm/p/11990998.html | 1.基本游戏的功能比较完善。2.简单、易上手的游戏操作。3.有背景音乐。4.界面较简洁。 | 1. 游戏中的文本字体显示不够清晰。2. 没有实现排行榜好友pk的功能，导致这个游戏不具有社交性，这样就难以吸引比较多的用户。3. 代码的注释还可以更加详细一点，以便于可能存在的项目交接的事项。也更方便代码的管理和修改。4. 只能实现当前得分和历史最高分，未能实现历史分数排行。5. 游戏的难度还需调整，游戏界面内可添加游戏说明（教程，武器介绍等）。 | 4 |
| 12 | 我有六点要说…… https://www.cnblogs.com/GDUTyhy/p/11992596.html | 1.基本背单词模块的功能比较完善。2.开发了背单词以外的小游戏功能（未上线），方便用户背单词后放松。3.界面比较美观大方。 | 1. ALPHA版本未发布，无法查看代码情况。2. 小游戏功能未上线。3. 背单词就仅仅只有记账的功能，没有更多的扩展功能（如阅读英语短文，单词发音），可能不具备得到大部分用户青睐的特殊性。4. 可以增加背单词的阶段奖励（小游戏中），实现那社交pk功能，这会更加激起用户背单词的动力。5. 未能添加背单词常见的“错题本”模块，背单词的效果可能没那么好。 | 11 |
事后分析报告（Q&A）
诸葛亮会议（谭万钏 摄）
设想和目标
-
我们的系统要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
本团队致力于打造一个基于云服务的学习平台，为学生与老师之间产生更多互动，促进学生的学习激情。本团队已经在之前明确定义好了本系统，即我们需要打造一个平台,能将我们的大学基本日常都“搬”到服务器上，通过平台，学生和老师们可以实时做想做的事，把传统的学习变得更加智能化和集中化。该平台能把课堂、社交等都集合起来。方便学生的校园生活，能让学生只在本平台上就完成了基本需求。对典型用户也有较清晰的描述，分为学生用户和教师用户两个典型用户，但对典型场景的描述尚有欠缺。
-
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
在Alpha冲刺阶段中，我们面临了很多除去软件开发以外的任务，因此在该冲刺过程中，本团队成员普遍感觉时间不够用，结果当然是没有最终达成目标。原计划的功能只做了最基本的5个（登录、学生提问、信息查询、问题发布、推荐信息），因考虑到大部分功能尚未完善，本团队暂时关闭注册功能，仅提供若干个内测用户作为测试，用户量也没有达到预期的数量。
-
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
对于内测用户的体验来说，他们都很赞同本学习系统的构想，但由于功能实现过少，他们还是希望能完善更多功能，最终肯定能捕获大量用户的肯定。离目标虽然还有一段路要走，但一直离目标越来越近了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经历了Alpha冲刺，我们懂得了很多，最重要的是一个团队之间的配合沟通，它往往决定了项目开发的效率和质量。
如果历史重来一遍，我们应该会加强团队成员之间的沟通，在开发之前讨论好各个成员擅长的方面。
计划
-
是否有充足的时间来做计划?
有
-
团队在计划阶段是如何解决同事们对于计划的不同意见的？
一般来说是组长听从各个成员的意见，在由组长“专政独裁”来决定该往哪个方向走，即组长决定了产品的方向。
-
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
工作没有最终完成，正如前面提到了除开发该系统之外还有学业上的事情需要处理；另一方面就是团队成员之间沟通有不少障碍，并且大部分成员之前并没有接触过系统开发，他们需要花费大量时间在学习软件开发上，导致整体开发效率并不高。
-
有没有发现你做了一些事后看来没必要或没多大价值的事?
整个开发过程做的每一件事都挺重要的，特别是对于团队第一次合作开发来说，无论每件事是好是坏，它都是我们团队合作中最宝贵的财富，也是一项人生阅历，每一件事都非常有价值。
-
是否每一项任务都有清楚定义和衡量的交付件?
因为时间仓促，每项任务的定义都没有很明确，但按照结果来看，成员之间还是比较清楚需要开发什么样的系统。
-
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
越到项目的末期，我们发现项目越多功能尚未完善，但是为了赶着上线，不得不将部分功能砍掉，因此开发到一半的代码必须备份好，并将其从产品中移除，对于Alpha阶段来说相当于做了一些无用功，出现这种情况的原因就是缺乏开发经验，整个开发过程并没有完全按照原计划走。
-
在计划中有没有留下缓冲区，缓冲区有作用么?
没有。
-
将来的计划会做什么修改？
做好团队沟通与分工。
资源
-
我们有足够的资源来完成各项任务么？
实际上本团队在资源上及其匮乏，导致本团队无法在Alpha阶段及时交付所用功能：
- 开发资源：大部分成员都没有接触过Java开发，他们需要花费大量时间来学习，各种技术文档他们没办法一下子能看懂。
- 设备资源：设备还是比较紧缺，另外就算有了设备，一个测试人员也很难同时正确操控多个设备。
- 时间资源：成员学习开发花费了大量的时间成本，其次是顾及其他学业的任务，还有个别成员需要到外地处理自己项目的事情，无法实时与团队交接任务。
-
各项任务所需的时间和其他资源是如何估计的，精度如何？
根据任务量与开发成员实际开发效率综合顾及时间，精度并不高，原因是高估了开发者的能力。
-
测试的时间、人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？
前面也已经提到了，各种资源都是不太够得，其中最缺的还是人力资源。
对于美工设计/文案也低估了其难度，实际上花在这些上面的时间要比开发的时间更多。
-
你有没有感觉你做的事情可以让别人来做（更有效率）？
测试和开发可能需要分工更明确一点，有时候边测试边调bug感觉效率很低。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
要对每个成员有更精确的评估，使得分工更加合适，让合适的人干合适的事。
变更管理
-
每个相关的员工都及时知道了变更的消息？
是的。几位开发人员更新代码后，都会上传至Github，并且在微信群通知大家；每位成员测试时发现接口文档有问题，都会及时更新并告知大家。
-
我们采用了什么办法决定“推迟”和“必须实现”的功能？
从两方面考虑，一是需求，二是实现难度。用户需求高的功能和基础功能是“必须实现的”，用户不那么需求的和实现难度大的功能可以适当推迟。
-
项目的出口条件(Exit Criteria - 什么叫“做好了”) 有清晰的定义么？
本系统的出口条件定义如下：
- 原计划的所都功能都实现。
- 每个功能都没有严重（能导致整个系统或服务器瘫痪）bug。
- 能够保证用户并发量在100以上，并且能够控制用户访问。
-
对于可能的变更是否能指定应急计划？
可以。比如发现了一个无法解决的bug，我们可以在github上回退至上一个正确的版本，再仔细寻找问题所在，或者召开紧急会议让所有成员进行讨论处理方案。
-
员工是否能有效地处理意料之外的工作请求？
大部分成员都能完成，少部分出现了调试花了很长时间的情况，但出现的几率较小。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
一个好的产品的规划能为开发过程提高不少效率，以后会把重心放在文档撰写上面。
设计/实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
我们一起商议了接下来等待完成的各个工作。由组长谭万钏来完成设计工作，他负责分配给每一位成员的所有任务，时间来说算是合适，可能有些工作交给其他成员做会更有效率。
-
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
对于产品接近上线时考虑功能删减的问题，大家的意见不一致，在砍功能的取舍有些分歧，最终大家通过分析团队的主方向以及自身技术水平来确定删减哪些功能。
-
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
由于本系统完成的功能较少，整个系统的规模就比较小，团队的测试工作主要用到的不同用户进行手动测试，每个功能都由测试人员像是用户那样去使用系统，然后反馈自己的使用体验以及问题单元测试也有用到本项目的测试中，其他比较少用到。
-
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
退出功能。因为退出功能会涉及到一系列数据的删除，如果少删或多删都有可能出问题，而且有些数据可能在之前就已经删掉了，所以也要加以判断。
当时写的时候主要关心的是实现这些功能，而对于这一个功能对其他部分的影响没有做全面的考虑。 -
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审由团队的开发人员进行，本团队的代码复审采用模块化交叉复审，即让每个开发人员复审不是自己开发的模块代码，使得能够复审出原来开发人员没有察觉的问题。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在一开始做之前要充分商讨要做什么？怎么做？谁去做？不然到后面很可能就会被遗忘或者互相推诿掉。
开始做之后最好能写个纸面上的思路，并不需要太正规，最重要是将所有问题都记录下来，不然每个成员都由自己的事情忙，最后会导致问题的疏漏。
测试/发布
-
团队是否有一个测试计划？为什么没有？
有，详细可看上一个随笔中的测试报告。
-
是否进行了正式的验收测试？
没有，因为时间比较赶只是将流程跑了一下看有没有什么问题。
-
团队是否有测试工具来帮助测试？
没有，采用的是人工测试。
-
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
软件的效能主要是指并发性和压力测试，这一点由于设备和人力原因并没有测试。我们只是使用几台机器进行测试，效果还可以。
-
在发布的过程中发现了哪些意外问题？
服务器不稳定，可能会死机，正常运行时也有可能会被暂停，得人工重启，而这时之前正在进行游戏的玩家数据就会被清除。
APP直接退出可能会导致一系列问题。
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
达到了CMMI二级。我们团队遵守了既定的计划和流程，有资源准备，权责到人。但是还没有一套完整的管理措施，没有制度化。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我认为本团队目前处于磨合阶段，因为经过了Alpha阶段，我发现我们团队的沟通效率提高了不少，但在其他方面还是有较大的上升空间，需要一段时间以及合作多一些项目进行磨合。
改进
- 通过Alpha阶段的相互了解，我们团队的成员之间更加了解，认识到彼此的特性，分配任务时也更贴合每个人特点了。比如某成员更适合找bug，我们就安排他去做测试人员。
- 团队的执行力更强了，虽然大家的时间都比较紧，但只要任务布置下来，都会挤出来时间去完成的。
团队目前最需要改进的地方
每个成员的开发技术水平都需要提高，这一点是本团队开发的一大瓶颈，通过该项目不仅要找到自己在哪些技术方面有哪些欠缺，还要知道自己在团队中所担任的角色，总之就是需要提高自身的技术水平，这能为团队效率有显著的提升。
团队成员在Alpha阶段的角色和具体贡献：
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
|---|---|---|---|
| 谭万钏 | PM | 30 | 项目规划、前端后端开发、产品部署上线 |
| 刘志豪 | Dev、PM | 24 | 后端开发、数据库设计、产品经理 |
| 谭艺 | Test | 21 | 后端开发、数据库管理 |
| 唐崇珂 | Dev、Test | 14 | 后端开发、项目单元测试 |
| 石林峰 | Test、Opt | 15 | 项目总测试，项目报告撰写，项目推广 |
| 刘霍翔 | Test | 11 | 项目总测试，报告撰写 |
