刚下飞机——Beta答辩博客
一、设想和目标
做这个项目的背景、意义是什么？要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 我们的软件主要解决大学生寻找问题解答困难，又不好意思去向老师同学提问，现有的社交平台难以满足他们的需求，于是我们的项目初衷是为这些大学生提供一个可以匿名提问的平台，同时吸引更多人来解答，来帮助他们解决问题。
- 定义得比较清楚
- 典型用户和场景：大学生A性格内向，在学习中遇到了一个问题，在网络上搜索并没有找到完美的解答。想去问同学老师却不好意思开口，学习群、班群又关闭了匿名，其他问答平台又没有针对性，提问要很久才能收到回答。于是我们的应用能为他提供一个匿名提问的平台，而且我们的平台专门面向大学生以及拥有详细的分类机制，并且有奖励机制能吸引大佬前来解答，能帮助A同学快速解决问题。
项目达到目标了么（原计划的功能做到了几个？在原计划之上是否有所拓展)
项目的目标达到了。
原计划的功能有：
| 模块 | 功能 |
|---|---|
| 用户前台部分 | 浏览，推荐，提问，回答，评论，回复，匿名，认证。注册，登录，赞同，反对，点赞，收藏，搜索，查看记录，修改资料，举报等 |
| 管理员后台部分 | 登录、退出、举报处理、认证管理等 |
| 在原计划之上我们的拓展： | |
| 模块 | 功能 |
| -- | -- |
| 用户前台部分 | 删除，邀请回答，查看他人资料等 |
| 管理员后台部分 | 查看用户统计数据、查看问题统计等 |
和alpha阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？
和alpha阶段相比，团队的软工质量有所提高。提高的地方主要体现在成员合作更加轻松，衡量标准是成员间通信的耗时。
设想用户量是多少, 用户对重要功能的接受程度和我们事先的预想一致么?
设想的用户量是100个各种专业大学生，通过调查来看用户对重要功能的接受程度和我们设想的一致。
有什么经验教训? 如果历史重来一遍，我们会做什么改进?
经验教训就是项目规划时没有全面地对现有的问答应用平台进行调研，导致我们难以做出具有特色的功能，应用缺乏竞争力。如果历史重来一遍，我们会认真对现有的类似平台进行调研，构想出更多更具特色、更有竞争力的功能。
二、计划
和alpha阶段相比，每天是否时间规划的更好?
是的。
团队在beta阶段是如何解决队友对于计划的不同意见的？
基本上没有不同意见，项目的功能都在开始前定下，如果在开发过程中有人对原有的计划提出不同的意见，则需要在给出自己的理由，并且估计变动带来的影响，然后由组长决定是否采纳该意见。
你们原计划的工作是否最后都做完了? 如果有没做完的，为什么?
都做完了。
是否每一项任务都有清楚定义和衡量的交付件?
是。
项目是否出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目的开发中没有意外，在部署过程中使用IDEA部署时，出现IDEA连接不上服务器的问题，最后使用手动部署。没有估计到的原因：对IDEA的部署不熟悉
在计划中有没有留下缓冲时间，缓冲时间有作用么?
有留下了缓冲时间。本次冲刺中缓存时间一半在每个功能完成后，用于审视代码或进行测试，还有一半放在最后，避免有些功能实现的进度过慢，不能按期完成
我们学到了什么? 如果重来一遍, 我们会做什么改进?
我们学习到了在制定计划时，一个好的原型可以帮助计划的制定，减少在开发时的讨论，此外，计划的规划要更加细致，如果出现估计误差过大，应该立即调整原定计划，避免整个项目的拖延。
三、资源
有足够的资源（可以是时间、开发资源等）来完成各项任务么?
有的。
各项任务所需的时间和其他资源是如何估计的，精度如何?
由完成该任务的组员自行估计，组长统筹兼顾
和alpha阶段相比，测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间、人力和软件/硬件资源需求更大，我们也投入更多，依然足够；还是低估了难度，很难制作出出色的美工
变更的组员工作如何？如果未变更是否项目完成效率会更高？变更的组员学到了什么？对于可能的变更是否能制定应急计划?
变更的组员主要从事的是接口文件的编写和对项目成果进行测试，工作完成的很好，如果未变更效率应该差不多。学到的主要就是新的技术以及和如何跟新的小组人员交流。能，将重要的部分交予别的组员，让新来的成员先从普通的工作起手，熟悉项目和团队
有没有感到某个成员做的事情可以让别人来做（更有效率）?有什么经验教训? 如果历史重来一遍, 你们会做什么改进?
没有，每个组员都各司其职，施展了自己的才能。代码重构花费了一些不必要的人力资源，如果重来的话，应该在开始的时候就定好规范。
四、设计/实现
项目是否经历重构？为什么需要重构？
项目后期我们对业务逻辑层进行重构，控制器层，以及这两个层里的常量进行归纳整个重构。至于为什么要重构，重构的首要目的就是要维护代码的唯一性，提升代码的可读性，以及缩减代码的冗余性，如果项目没有进行适当的重构，难免会存在多人编码风格不一，代码存在本可以直接复用的冗余代码等问题。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的UML文档和现在的状态有什么区别？这些区别如何产生的？是否要更新UML文档？
我们团队从一开始就采用了junit进行单元测试，以及Microsoft vidio来绘制uml图数据流图等，Chrome插件postman进行接口测试，这些工具是有效的，能显著提高我们的工作效率。项目开始时的UML文档和现在有一定的区别，这些区别主要产生于开发的不可预知性，在设计过程中会有对开发所需要的资源有所遗漏。
什么功能产生的Bug最多，为什么我们在设计/开发的时候没有想到这些情况?
在beta阶段中，产生bug较多的是首页的推荐采用的推荐算法，会出现这种情况主要原因是由于对算法的不熟练以及没有考虑到推荐功能与其他功能的关联性。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审后期主要由小组指定成员完成，总体来说严格的执行了代码规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在beta冲刺的过程中，我们主要加深了对之前知识的学习深度，以及相关扩展工具插件的使用，再来一遍的话我们会在设计过程中对实现进行大概的构想，以减少后期开发过程中对初始设计的变更。
五、测试/发布
和alpha阶段相比，测试工作有提高吗？在哪些地方提高了？
相比alpha阶段，测试有了更完善的方式。我们是前后端分别测试，测试有单元测试、性能测试、页面测试。其中后端主要有，后端API、单元测试、性能测试；前端由于基础一般，测试主要是通过console.log()和f12控制台查看网络的接口调用情况来测试。
团队是否有一个测试计划？
有，但是不算完善，不过相比alpha更有目的性和效率
团队是否有测试工具来帮助测试？
后端API：PostMan；单元测试:junit；性能测试：Jprofiler、Jmeter
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
团队通过使用Jprofiler、Jmeter来跟踪查看软件的效能，从软件的实际运行结果看，这些测试工作很有效，对于哪一块消耗了大量性能，能够准确捕捉。改进的话也许是需要对于测试工具功能的进一步开发，并进行覆盖面更广的测试
在发布的过程中发现了哪些意外问题？
暂无
我们学到了什么? 如果重来一遍, 我们会做什么改进?
alpha阶段我们的测试计划不太完善，导致有很多bug，因为代码量积累很大，找bug花费了很多时间，但是beta阶段我们安排了专门的测试人员，边写边测试，代码质量和功能完成度大大提高。如果再来一次，我们会更早的提出完整完善的测试计划，从一开始就有边写边测试并安排专门测试人员，并提前学习测试工具的一些进阶功能。
六、团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
通过各个人的学业状况和个人意向实际情况进行角色划分，主要分为前后端。当然，有一些没有学习过的技术就需要私下学会掌握和使用，让自己能够比较好的加入到项目中去。
团队成员之间有互相帮助么？
有，当任务分配完时，如果有人先完成了任务，就会参与到测试或者修复Bug，也会帮助那些没有时间的人实现一些DAO层或者Action层的代码。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
通知组长和前后端交接的负责人，要求开一个小型的会议来进行沟通，收集各方的意见，然后选择较好地方案。
七、总结
组员们自我总结
| 学号 | 姓名 | 自我总结 |
|---|---|---|
| 221701317 | 卓晓鑫 | 因为之前已经有过一次冲刺经历，这次计划的时候就有吸取了Alpha的教训的去做计划，但在冲刺过程中还是发现有不少的遗漏点，而且也发现了吸收的教训不应该只局限于本组，也应该去看其他组的经验教训，甚至去看看往届的作业，这才能让我们更快的成长。在开发中，我也碰到了许多问题，这些问题有些不少是没有接触过的、没有想到的，就在这样不断的发现问题-了解问题-解决问题的循环，这不光考验我的掌握的知识，还考验了我面对未知问题的分析、解决能力。此外，通过整个课程下来，我也对一个web系统、软件工程的开发流程有一定的了解。 |
| 221701319 | 郭秋中 | 在7天的beta冲刺过程中，完善了之前的项目，通过修改之前的Bug，还有增加一些在alpha项目中没有的功能，使得系统跟加的人性化。在其中，我学会了如何更好的和团队进行合作，将个人的优势发挥出来，促进项目的更好进行，当然也学习了一些没有接触过得知识，明白在一个项目中各个角色之间如何进行对接，提高项目进行的效率，根据接口说明文档进行编写代码可以极大的加快打代码的速度。在这次项目中积累的经验可以很好的促进以后的学习工作。 |
| 221701328 | 张春翔 | 经过了短暂的七天，我们的项目终于迎来了尾声。从几乎是一个空壳，到现在的“勉强能用”，我可谓是感慨颇多。对我来说这次项目是第一次真正意义上的团队合作，也是第一次体会到赶死线的辛苦。不过看着我们的项目一天天的充实，总觉得过去的辛苦也是值得的，真的是成就感满满。总的来说，整个冲刺下来，我收获到的不仅是知识方面的提升（因为真的学了不少东西），还有就是对未来获得了更多信心。在这次冲刺之前，看网上的消息总认为程序员的工作非常多，不止一次怀疑自己以后能不能坚持下去，经过这次时间短任务重的冲刺，我终于认识到了我自己所拥有的毅力与能力，对未来不再担忧，我也相信毕业后的我能经受起工作岗位的考验（哪怕是996）。 |
| 221701333 | 池政涛 | 在beta冲刺阶段中，我们在alpha阶段的基础上实现了一些次要的功能，这让我们的项目看起来更加的完整。在这个过程中，除了对相关知识的运用更加熟练之外，也锻炼了测试的能力。这个项目过程中收获了很多，代码规范的重要，相关组件的运用等等都能大大提升我们的编码效率。正所谓磨刀不费砍柴功，事前做好充足的准备，才能真正做到事半功倍！ |
| 221701337 | 朱凯文 | 在beta冲刺阶段中，开始接手管理员后台，花了几天时间深化了vue的学习，并从事了交互工作，深深感觉到前后端交互的接口设计是一门学问，一个好的接口可以让前后端的工作量减少，也可以避免后期各种修改参数和返回值。相比alpha阶段使用已经设计好的接口，亲自上手后对于两端的工作都有了更深的了解，明白了怎样设计能给两方减轻压力。总的来说，收获满满，深刻体会了团队开发和web开发的过程，让我对自己的能力有了准确的认知，我会从这次实践中吸取教训，做好总结，为自己的未来做好准备。 |
| 221701338 | 郭福强 | 在β冲刺阶段中，我和队友一起开始制作管理台后台界面。由于在一开始的时候沟通得不够，徒增了许多不必要的工作量。甚至做了许多重复的工作。在渐渐磨合的过程中，我对团队合作的重要性有了更深的理解。在遇到问题的时候，因为没有及时对问题进行反思，总结，因此总是出现重复的问题，极大的降低了开发效率。然后在这次的项目中我发现了自己工程能力确实还有待提高。由于我对新技能的不熟悉导致了项目进度较为拖沓，在此之后我会更加努力学习新技能，为未来走上工作岗位打下良好基础。 |
| 221701340 | 胡海江 | 重构代码花了我两天的时间，但是实际上对项目的优化没有贡献，只是为了规范一下格式，将所有的业务逻辑都放到Service里。由于经验的不足，这个在一开始写的时候是没有考虑到的。应该平时多练习，多去看别人的优秀代码。中途遇到一些技术的难点，最终靠自己解决了，在项目的实践中我收获了很多的经验。之前写的关于匿名的显示的代码，在队友重构时反应不清楚，尽管我在之前写的时候已经将功能提取出来，新建一个函数，但应该还是注释写的不足，或者代码的可读性太差。还是需要多多练习。 |
| 221701401 | 黄素芳 | 项目来说，因为是beta其实项目已经比较完整了，相对来说没有alpha那么辛苦。换过来的这组的工作模式相对自由，需要更为主动，对我来说是比较难的，尝试写了俩接口之后，最终没有跨越这个坎，选择了一个相对摸鱼的工作——测试（这样就不用自己主动领了=-=）。测试过程中感觉到有一些bug真的很神奇，大概也是因为我对相关的技术不熟悉的关系。技术因为两边不一样的缘故需要学习，不禁感慨与mabatis相比，Hibernate确实要写的比较多=-=，mybatis需要构造其他的需要的函数的话，一般只需要函数声明加个注解里面写上sql就差不多了（由于时间紧并没有涉足xml部分），Hibernate得写个具体的函数，感觉跟jdbc类似，学的时候看的一些资料也是将一些Hibernate的类跟jdbc做联系以便于理解，而且如果使用纯的hql的话有的sql的函数没有办法使用，还有就是体会到了springboot的便利。 |
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
在CMMI二级，管理级。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段
八、提高软件工程的质量
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
- 提高质量：可以考虑采用一些专业的代码质量的工具
- 代码复审：我们组复审机制还不完善，之后可以考虑在开发时，每周/每次冲刺随机匹配成2人小组，由2人互审代码
- 代码规范：主要依靠IDEA中的阿里巴巴代码规范插件进行检测
整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
- 在架构上，我们组现在采用的Struts2可以改用SpringMVC，还有采用负载均衡来扩大支持的用户规模
- 重构方面，一是不少对数据库的查询分成了多次，可以考虑改成多表查询或者创建视图，减少数据库的连接；二是现在接口返回的JSON大多是在业务层构造MAP，这样构建的代码十分复杂，不好，可以创建DTO类及其工厂类，来构建返回的数据
- 衡量质量：一是项目的性能(使用的内存、使用的CPU、响应时间)，二是代码的阅读性
其它软件工具的应用，应该如何提高？
应该多学习IDEA和Github的使用方法，还有多学习些其他的测试工具(Swagger、Fiddler等)
项目管理有哪些具体的提高？
在Bug/缺陷管理上尝试采用了看板来记录和管理。
项目文档的质量如何提高？
- 应该在开始撰写项目文档前统一文档的规范，最好可以给出一个模板和样例，让文档的撰写更加高效且阅读时也可以快速获取信息。模板的设计主要还是要多去参考其他项目的样式，结合文档需要传递的信息来设计。
- 在项目文档的管理上，可以采用在线文档(如：腾讯文档、Showdoc、Wizard等)或Github之类有协作编辑和版本控制的工具管理
对于人的领导和管理， 有什么具体可以改进的地方？
在管理方面，团队目前的结构偏向于民主集中制，导致团队成员之间通信耗时较大，在管理方面可以将团队向控制分散式结构靠拢，这样既能缩短团队的通信开销也可以兼容部分控制集中式团队结构的优点。
