RATE-MAX----beta答辩博客
beta答辩博客
设想与目标
做这个项目的背景、意义是什么？要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
为大众提供一个匿名聊天、倾诉心事的场所。定义为匿名性强、不以交友为目的的聊天软件。针对传播不法、违规信息的用户、进行不符合道德交流的行为制定处理方式。
项目达到目标了么（原计划的功能做到了几个？在原计划之上是否有所拓展)？
基本达到目标。
未完成的功能点：
原计划中，客户端是有广告页的，但是实现时发现我们还没达到商业化软件的地步，就没去实现。
有修正功能要点的模块:
原计划中，“漂流的记忆”（漂流瓶）功能，是有点类似“随机接力填写内容”的漂流瓶功能，但是因为讨论研究不足，后来模块实现时变成了传统的漂流瓶功能，最后应急修改了一些，但还是不少地方与初衷不符。
附加功能：
原计划中，是预计不支持图片上传相关的功能的，后来参考了别组的经验，成功在头像和动态处加上了图片上传的功能。
不足部分：
界面UI和一些交互还是不够合理，其中的比如聊天室部分原本打算用热榜形式推荐，后来遗漏实现了，不过有附加增加区分列表的显示。
和alpha阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？
和alpha阶段相比，软件工程质量是有提高的，其中最明显的就是经过alpha冲刺的经验，我们更加注重前后端的交流，可以看到前后端人员配合更加密切，同时接口的约定不再只是简单的用交流的方式，而是直接细致到共享文档，以便能够留下记录并提高开发效率。同时，提倡将遇到的问题记录到共享文档中，能更好的看到每个人的进度，及时进行开发的必要干涉。
设想用户量是多少, 用户对重要功能的接受程度和我们事先的预想一致么?
设想的用户量大概为100左右。用户对重要功能的接收程度较好，没有提出关于聊天功能的一些意见或者需要改进的点，但是对于一些界面及交互还有些不合理。
有什么经验教训? 如果历史重来一遍，我们会做什么改进?
1.美工吧，从用户反馈中来看有点太过于忽略美工的重要性。同时一些用户的交互还是有不合理的地方。
2.小部分模块在整合后的测试还是有发现许多问题，所以还是应该监督好每个人把自己的模块尽量考虑得周全一点，避免后面出现过多问题。
计划
和alpha阶段相比，每天是否时间规划的更好?
和alpha阶段相比，我们让每个人每天的工作细化下去，记录在在线文档中，同时每天晚上对小组成员的进度实时查看并在leangoo中更新，可以看到组员每日记录更加认真，时间规划也更加好。
团队在beta阶段是如何解决队友对于计划的不同意见的？
对于组员的不同意见都是在站会中提出共同讨论解决，一般是组长发表一个自己认为的观点，然后再看组员的其他观点，最终不行就投票决定意见，但是组员都比较和睦，没有出现这种需要的投票解决的不同意见。
们原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划中，客户端是有广告页的，但是实现时发现我们还没达到商业化软件的地步，就没去实现。
是否每一项任务都有清楚定义和衡量的交付件?
是有明确的交付件的。大部分功能总体上与原本定义的没有太大差别，小部分功能如漂流瓶没有做到前期预想的类似“随机接力填写内容”的漂流瓶功能，而是更倾向于传统的漂流瓶功能，但是由于原本这只是娱乐功能，便也没有进行更改。
项目是否出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
前期在选择技术时选择了ssm，前期环境的配置给我们造成了挺大的麻烦。
造轮子造出来的websocket连接模块，经常出各种莫名其妙的问题。
漂流的记忆模块，开发成果与最初的设计有一定的差异
缓冲时间
有预留时间，如完善阶段预留了一天时间，开发阶段预留了两天时间，用于测试和追赶进度。
资源足够吗？
前端的参考资料以及辅助工具资源不足。其他的整体上还算足够。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
各部分模块人员应更认真进行测试，以免后期整合后发现错误修改不便而且对项目进度产生影响。
前后端应该有更多预留时间，以供解决完善发布后出现的一些问题。
知识还是需要巩固得更深一点，以免开发时效率过低。、
资源
有足够的资源（可以是时间、开发资源等）来完成各项任务么?
因为在alpha冲刺到beta冲刺有一定得休整时间供组员去学习了解新知识，所以这段时间是够组员去巩固知识的。
对于一些硬件的资源，如云服务器和云数据库的限制。
和alpha阶段相比，测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
相对alpha阶段而言更好了一些，但仍然有些不足，主要集中在能力差距上带来的偏差。美工上，确实有点考虑不足，最后时间比较紧，只能做一个风格基本统一，没能很充足地进行完善。
后端的话有让同学去进行一系列的单元测试，接口压力测试，但是感觉其中有些部分用户量大的话可能还会出现问题。
变更的组员工作如何？如果未变更是否项目完成效率会更高？变更的组员学到了什么？对于可能的变更是否能制定应急计划?
变更的组员在站会、讨论提意见方面较为积极，但是在接口的开发和设计方面后期经测试出现的问题较多。
如果未变更项目的开发效率应该会更高。
学到了什么参见总结博客。
有提前让他去学习一系列相关知识并了解项目，应急计划的话就是将原本的聊天功能的实现交给另外的人来做。（因为重新学习netty成本较高）
有没有感到某个成员做的事情可以让别人来做（更有效率）?有什么经验教训? 如果历史重来一遍, 你们会做什么改进?
来自前端管理人员的看法：
有，但是会引起任务分配不均的问题。历史重来的话，我想牺牲一些模块化的优点，将任务分配的粒度更精细一些，使得简单的任务交给能力较弱的人来做，比较困难且重要的任务交给你能力较强的人来做，避免能力较弱的人因为任务难度卡进度，能力较强的人因为任务简单但量大而卡进度。
设计/实现
项目是否经历重构？为什么需要重构？
重构方面，我们前端注释较多，基本上各个地方都有对应的解释，然后聊天相关的部分因为都重构扩展过一遍，所以二次重构难度并不大。、
前端因为分配粒度大（也因此带来了一些任务细节的问题），正是因为粒度大，所以很大程度上高内聚低耦合，在此基础上修改或者重构也问题不大。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的UML文档和现在的状态有什么区别？这些区别如何产生的？是否要更新UML文档？
有进行单元测试，开始的uml和现在的状态有些不同，其中一些模块的整体关系，逻辑当初没考虑清楚，甚至到更新uml.
什么功能产生的Bug最多，为什么我们在设计/开发的时候没有想到这些情况?
Websocket当属第一，解决这方面的问题至少解决了五六次，前后加起来得有两三天。设计开发时，没想过会这么容易断掉连接，而且也没想到只要稍稍没处理好一处异常，这一块就会全线崩溃。
其次便是朋友的推荐，其中在测试过程中发现许多推荐的朋友不合理的地方，如被封禁用户，黑名单用户等等，这些后期都进行了进一步的完善。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审采用不同模块的人去测试，同时又专门的测试人员进行查看，整体上执行了代码规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
有时候有些东西在设计时考虑得不够仔细，导致到开发时需要讨论修改，影响了开发效率。
对于一些任务划分应该将简单的任务交给能力较弱的人来做，避免出现项目卡进度得情况。
测试/发布
和alpha阶段相比，测试工作有提高吗？在哪些地方提高了？
前端方面，始终没找到能测试mui和h5+的工具，后面谷歌浏览器的真机模式与阿里云的移动测试一直用不了，就没法进行比较数据化的测试。只能开发过程中连接mumu模拟器进行功能点的开发测试，然后利用hbuilderx里的内置浏览器再结合组员的真机进行多种界面的UI适配的测试，最后进行团队内部的模拟用户体验测试。
后端方面，各个模块开发进行了单元测试和postman测试，同时，也进行了接口得压力测试。
团队是否有一个测试计划？
完成一项功能模块后便进行测试，同时后面有单元测试和接口测试。
团队是否有测试工具来帮助测试？
单元测试（IDEA，Junit）
POSTMAN（接口测试）
JMETER(压力测试)
hubilder+模拟器+真机（前端）
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
结合hbuilderx的控制台日志输出与流程检验。后续根据这些内容，部分地方利用了缓存加载的方式，使得软件的更快捷了一些。
测试效果：界面得使用有进行功能得评估，对程序的实现有较大帮助，大部分模块没有出现较大问题
改进:测试用例可以多一些，同时测试的时间得再长一点。
在发布的过程中发现了哪些意外问题？
发布后，出现了大大小小得问题，其中也增加了更新日记对问题进行了汇总。详情请看软件个人中心右上角下拉栏更新日志。
同时，在项目部署到服务器时，用netty构建得聊天服务器有时出现断开连接的现象，明明心跳时正常的，却还是断开，代码明明一样，重新部署后却没了这个现象。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
软件得测试和发布后得用户反馈功能修改应该留更多得时间。
团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
首先功能模块得划分由前后端各一位同学进行划分分配，在没有异议得情况下进行在线文档得构建，跟踪组员开发进度。人尽其才方面，有些组员能力较为薄弱，但在其他组员的帮助下，最终也实现了功能，基本实现了人尽其才吧。
团队成员之间有互相帮助么？
有。遇到问题时，组员会主动向组长反馈或者在群中直接提出，我们也会在每日站会中就组员在在线文档中编写的问题困难点询问解决情况，组员间能很好的互相帮助，共同解决。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
一般都是开会讨论决定的。
总结
组员们自我总结
见总结博客。
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
第三档次吧。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段，能够按照规定完成任务。
提高软件工程的质量
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
代码复审只采用人工测试人员复审，提高得话可以采用插件简化过程。
整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
可以使用代码重构。在代码复审和测试得过程将发现得冗余得类或者冗余得方法进行抽离/提取，同时，尽可能复用类得功能和方法。其次是对数据库的操作层面上可以对程序的架构提高，项目中经常出现重复查询的情况，可以通过视图的方式或者连接查询的方式减少查询次数。
其它软件工具的应用，应该如何提高？
github的使用应该有跟深一步的了解，同时对于测试工具很多只停留在表面，应该跟进一步去理解掌握。
项目管理有哪些具体的提高？
任务追踪更加明确精细。
对于人的领导和管理， 有什么具体可以改进的地方？
有些组员出现回复慢的情况，有些组员能力上有不足的点，这些在组员任务分配的时候应该有更进一步的考量，考虑把简单的任务分配给能力上稍微不足的人，同时调动组员积极性，不要让组员回复慢、效率低的情况影响到小组氛围。
项目展示
项目的几个功能点
