| 这个作业属于哪个课程 | <2020 春 W 班 (福州大学)> |
|---|---|
| 这个作业要求在哪里 | <作业要求> |
| 团队名称 | <旗山的骄傲> |
| 这个作业的目标 | <Beta 冲刺> |
| 作业正文 | <作业正文> |
| 其他参考文献 | <《构建之法》> |
part.01 设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
-
解决问题
- 服务于高校师生，集任务发布、物品租赁、失物招领及其他附加功能的校园综合平台。解决了高校日常生活中需要解决难题时需要发布任务的情景；解决了对某类物品急用时物品租赁的场景；解决了丢失/捡到失物时失物招领的情景；解决了找人/找群/找历年卷时使用附加功能时的场景。
-
定义是否很清楚
- 定义较为清楚
-
是否对典型用户和典型场景有清晰的描述
- 有针对四个模块对典型用户和典型场景有清晰的描述（见下）
-
发布任务
典型用户：刘志勇
用户需求：代领快递
场景描述：
雨天，一位名为刘志勇的大学生收到了一条快递信息，要去5区在19：00前领快递，但是他不想出门，又不知道专门的代领快递的组织，这时他点开了手机上的“校园芥子空间”app，点击“发布任务”，发起了高额悬赏——5元，不到五分钟就有人接了单，在一小时后给他送快递上门，伴随着“尊敬的刘先生，你的快递到了”的话语以及支付宝到账的提示音，任务结束。 -
物品租赁
典型用户：刘志勇，黄晓东
用户需求：出租衣服，租赁衣服
场景描述：
31日，这个月的最后一天，还是那位刘同学，手头紧张，想靠出租体面的衣服来换取几顿饭钱，便打开了校园芥子空间，进入物品租赁的页面，发起了租赁。片刻，同样在使用校园芥子空间的同学黄晓东看见了这条租赁信息，那体面的衣服每天只需要不那么体面的10元便能穿在自己的身上，想到这他迅速的发起聊天和刘同学谈妥了具体事宜，交易完成。 -
失物招领
典型用户：黄晓东
用户需求：寻找失物
场景描述：
上面的那位黄同学记性不好老是丢东西，今天他把校园卡丢了。已经习惯使用校园芥子空间的他第一时间打开了app，熟练的发布了失物招领信息，数小时后响起一阵敲门声，他打开门一看，是拿着他的校园卡来归还的刘同学，还不忘说“来一杯一点点的四季春”。黄同学的校园卡失而复得，失物招领的任务完成，在app上又发布了代买奶茶的任务…… -
历年卷
典型用户：刘志勇
用户需求：找历年卷
场景描述：
期末周了，刘同学开始复习了，但是没有历年卷可以参考的话心里就没有底气，于是他情不自禁的打开了校园芥子空间，点开了其他功能，惊喜的发现这里居然有接下来几门考试的历年卷，忐忑的心放了下来，PPT翻页的鼠标点击声也大了几分……
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
-
原计划的功能
- 原计划功能三大模块基本完成，附加功能模块预计于本阶段完成，详细完成情况见下
-
是否按照原计划交付时间交付
- 基本按照原计划交付时间交付，上阶段燃尽图成功燃尽，静待花开
-
原计划达到的用户数量达成情况
- 暂未未达成，预计在发行版推出后进行推广
截止Beta阶段前各部分现实进展
web前台
| 对应模块 | 完成情况 | 存在问题 |
|---|---|---|
| 登录模块的各部分界面：登录、注册、忘记密码界面 | 基本完成 | 目前只实现了登录模块，可以进行正常的登录 |
| 主界面：实现对各模块进行跳转的主页面 | 完成 | 主界面主要是一个导航页，通往各个页面的风向标 |
| 发布任务、失物招领、物品租赁各模块的基础界面：总览、查看详情、发布、查看个人发布、搜索界面 | 基本完成 | 待完善 三个页面都实现了基本功能，查看详情，发布任务，查看评论。点赞以及实时评论尚未实现 |
| 其他界面：查看个人信息、修改个人信息等界面 | 未完成 | 时间关系，没有实现。 |
| 各模块的基础测试 | 完成 | 各个模块的基本功能都完成，没有问题 |
| 前后端完成交互 | 基本完成 | 因为后端这次是几位同学一起开发，导致后端的数据在不同模块的相似接口中的类型不一样，如一个是驼峰一个是下划线，在组件开发的基础下，导致工作量增加 |
web后台
| 对应模块 | 完成情况 | 存在问题 |
|---|---|---|
| 登录模块的各部分界面：登录、注册、忘记密码界面 | 基本完成 | 无 |
| 用户管理模块的界面：总览、查看详情、搜索界面等界面 | 基本完成 | 无 |
| 管理员管理模块的界面：总览、查看详情、搜索界面等界面 | 基本完成 | 无 |
| 任务管理模块的界面：总览、查看详情、搜索界面等界面 | 基本完成 | 无 |
| 失物管理模块的界面：总览、查看详情、搜索界面等界面 | 基本完成 | 无 |
| 物品管理模块的界面：总览、查看详情、搜索界面等界面 | 基本完成 | 无 |
| 评论管理模块的界面：总览、查看详情、搜索界面等界面 | 基本完成 | 无 |
| 敏感词管理模块的界面：总览、查看详情、搜索界面等界面 | 未完成 | 未实现接口（β阶段完成） |
| 各模块的基础测试 | 基本完成 | 未完成全覆盖的测试 |
| 前后端完成交互 | 基本完成 | 未实现预期的所有功能 |
Android
| 对应模块 | 完成情况 | 存在问题 |
|---|---|---|
| 登录模块的各部分界面：登录、注册、忘记密码界面 | 基本完成 | 后端的注册和登录接口存在一些问题，暂时无法全面完善，因为用户还没完成用户的验证功能，所以忘记密码这一功能也还没实现 |
| 主界面：实现对各模块进行跳转的主页面 | 基本完成 | 主界面是最花时间的部分，目前已经基本完成，但是RecyclerView的缓存问题还没有解决 |
| 发布任务、失物招领、物品租赁各模块的基础界面：总览、查看详情、发布、查看个人发布、搜索界面 | 基本完成 | 目前的数据不多，没有实现搜索功能，下次完善 |
| 其他界面：查看个人信息、修改个人信息等界面 | 未完成 | 时间关系，没有实现 |
| 各模块的基础测试 | 完成 | 无 |
| 前后端完成交互 | 完成 | 有一些后端设计的接口和前端的应用存在偏差，这些问题会在下一个阶段统一反馈，统一解决 |
后端
-
框架内接口部分
| 对应模块 | 完成情况 | 存在问题 |
|---|---|---|
| 完成对应各个模块（用户、管理员、任务、失物、物品、评论、敏感词）的接口 | 基本完成 | 敏感词使用tried树，本次未投入使用（β阶段使用）、各模块因三人开发，需要在下一阶段进行一定的代码重构 |
| 使用springboot框架内置的spring-boot-starter-test对框架内部进行测试 | 完成 | 无 |
| 使用Postman对接口进行初步测试并保留测试结果 | 完成 | 测试出各模块因三人开发，有部分返回数据还需进一步统一规范 |
| 完成在线接口文档为前端提供对接依据 | 完成 | 有部分接口描述不当，影响前端阅读（已修改） |
-
工具类部分
| 对应模块 | 完成情况 | 存在问题 |
|---|---|---|
| 基础工具类的编写：Json工具（封装接口返回数据）、Date工具（封装日期格式等）、Des工具（加密密码）、File工具（文件上传接口的封装及异常返回处理） | 完成 | 无 |
| 使用Junit对工具类进行单元测试 | 完成 | 无 |
-
服务器端
| 对应模块 | 完成情况 | 存在问题 |
|---|---|---|
| 初始化服务器：Tomcat的初始化、mysql的初始化、niginx初始化 | 完成 | niginx初始化还未进行代理（β阶段完成） |
| 部署项目：后端打包war包部署开放端口接口->部署前端项目 | 完成 | 未进行代理前端页面访问较慢 |
项目管理
| 对应工作 | 完成情况 | 存在问题 |
|---|---|---|
| 创建在线接口文档、在线每日工作文档、在线每日会议记录文档、在线工作量化文档 | 完成 | 无 |
| 创建teambition管理项目、上传更新量化后的工作 | 完成 | 任务量化为每人为自己的量化，每人对应任务量不平均 |
| 创建github组织，创建团队仓库（团队文档以及代码规范）、创建开发成员分支（6） | 完成 | 有一成员未在分支进行开发 |
| 创建博客园博客：总结博客、冲刺计划博客、每日冲刺博客、汇总博客 | 完成 | 无 |
| 每日在线每日工作文档更新、每日在线每日会议记录文档更新、每日teambition管理（任务完成及统计信息记录）、每日站立式会议、每日博客园博客更新 | 完成 | 有任务逾期完成 |
燃尽图
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
-
团队软件工程的质量提高情况
- 和上一个阶段相比，团队软件工程的质量提高了
-
提高的情况
- 团队合作方面：提高了每日站立式会议的效率，表现在会议时间缩短的同时且汇报速度提高；前后端交互新增了前端反馈使用的在线文档，加深前后端的线上交流
- 项目管理方面：沿用teambition的同时，优化了任务量化的方式，成员对应任务的分配更加平均，粒度更高；使用第三方（爱图说）绘制任务总量变化曲线，更为直观；增加了冲刺期间对开发、测试人员每日提交签入的要求，上传记录截图，每日对贡献比进行计算；沿用在线文档辅助项目管理，优化了在线文档的排版，更加适应于新阶段的作业要求
- 代码质量方面：前后端均对之前代码进行了一定重构，前端优化界面，后端重构代码，规范了三人编写的后端；团队成员依然在不断增加知识储备，总体代码质量在一直提高中
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
-
用户量, 用户对重要功能的接受程度与预想的一致性
- 目前功能还未全部实现，暂未对用户开放测试，遇见在发行后再进行大量推广测试，在不断向目标前进中
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
-
经验教训
- 因三人编写后端，同类型接口提交参数形式有差，造成了不规范统一的问题
- 前后端交互，线上交流信息有参差，导致时间的浪费
- 上阶段前端测试时间安排不合理，导致测试覆盖率较低
-
改进
- 后端制定更全面的统一规定，加深交流与联系，更加统一规范
- 前后端加深交流，会议时多交流，会议下通过文档、聊天工具等更多的交流信息
- 测试伴随开发进行，时间管理，合理安排时间
part.02 计划
是否有充足的时间来做计划?
-
冲刺前
- 在正式开始冲刺前我们会提早开一次会议，来制定冲刺计划和任务分配，一般预留2-4天来预防突发情况，得益于teambition的使用和组长的安排以及组员的配合，所以我们是有充足的时间来制定计划的
-
冲刺中
- 在正式冲刺中，每日每位成员都会在每日工作的在线文档中完成昨天的成就、遇到的困难、今天解决的进度、明天的计划、心得体会等，每日完成一部分的任务并做一部分的计划，所以我们在开发中的计划时间也是充分的
团队在计划阶段是如何解决同事们对于计划的不同意见的？
-
解决方法
- 先由组长拟定初步计划，如有异议，则成员提出问题，征求各个组员的意见，探讨提出的原因以及合理性，最后投票，大多数人同意的通过
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
-
原计划的工作完成情况
- 原计划工作基本完成，有部分细节未完成，详细情况见上部分表格
-
原因
- 本小组的项目相较于其他组模块较多，且前端有三个端，时间较紧有部分未完成
有没有发现你做了一些事后看来没必要或没多大价值的事?
-
例举
- 目前看来所做的事都是有意义的，只有性价比高低的区别，例如分工安排工作量是非常有价值的事，而相对可能在项目管理上使用了多方的软件进行管理，占用了不少时间，相对性价比较低，但效果不错
是否每一项任务都有清楚定义和衡量的交付件?
-
现实情况
- 每一项任务都有明确的定义，衡量的交付件也由组员探讨得出。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
-
现实情况
- 项目大致按照计划进行，除了在前后端交互和部署服务器出现了些问题，这是没有预料到的，因为这是第一次的完全线上开发，这是平日线下合作所没有遇到的，由于服务器的MySQL版本过低，导致前端调用接口返回错误，原因是未统一数据库版本。
在计划中有没有留下缓冲区，缓冲区有作用么?
-
现实情况
- 我们在冲刺前预留了2-4天缓冲时间，为项目提高容错率，学习新知识，冲刺的准备，事实上也用到了这段预留下来的时间，达到了它的效果。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
-
计划的修改情况
- 保留缓冲时间，如重要的功能进度落后则必须加班在期限内完成，不能拖到预留出来的时间，缓冲时间则是用来修改细节的问题，例如交互问题，修复bug等。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
-
收获
- 一个合理的计划可以提高效率，同时减轻成员的压力，制定合理的计划是一项非常重要的能力，做好计划能够事半功倍。
-
改进
- 重来一次的话我们会选择增加制定计划的时间，而不是像过去那样匆忙，才能充分利用时间、提高效率，少走弯路。
part.03 资源
我们有足够的资源来完成各项任务么?
-
时间
- 项目功能复杂，模块较多，对应前端最多，时间上是不充足的
-
技术
- 本团队成员编码能力较高，完成本项目所需的技术是足够的
-
服务器
- 服务器为学生机，带宽，内存等明显不足以应对本项目预期的并发负载
各项任务所需的时间和其他资源是如何估计的，精度如何?
-
时间
- 开发的预计时间为按照开发人员经验预估，有一定误差
-
技术
- 成员项目经验较为丰富，可以满足
-
服务器
- 开发成本较低，服务器资源不足为预计之内
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
-
测试、人力和软件/硬件资源方面
- 前端测试时间较紧，后端测试时间充分；前端由于一人负责一端人手较紧，后端三人有余；软件资源足够，硬件方面个人开发设备绰绰有余，服务器配置不足
-
美工设计/文案
- 在美工设计和文案方面确实低估了其难度，这方面主要由组长负责（相当业余），文案完成情况在预期值附近，但美工方面alpha阶段的成品视觉感官上没有达到预期的效果。
你有没有感到你做的事情可以让别人来做（更有效率）?
-
现实情况
- 可能会因为擅长的领域有所不同导致某些事情让其他人来做更高效，有的同学可能更为擅长与文档攥写、有的可能擅长与管理作为leader、有的可能更为擅长开发，但是实践本身也是一种学习，所以在时间允许的情况下期望能够让每位成员多学习新东西，有所收获。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
-
经验教训
- 要准确根据当前的资源来判断估计任务的难度和所需花费的时间，提早开始冲刺预留时间提高机动性，前端测试覆盖面低就是安排不当导致的
-
改进
- 给予简单的任务更早的完成期限，困难的任务更长的时间，更为恰当的对资源进行分配，这样不会造成简单的任务拖延时间过长，造成人员时间上的浪费
part.04 变更管理
每个相关的员工都及时知道了变更的消息?
-
现实情况
-变更的信息我们会在组内的群里以发布公告的形式通知，并在每日的站立式会议中确认每位组员是否已获知新信息。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
-
现实情况
- 由功能对项目整体的重要性决定，例如历年卷功能由于并不为主要功能，则推迟至beta阶段，如物品租赁等三个功能和登录注册是综合平台的核心部分，规定为“必须实现”的功能，在alpha阶段必须上线。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
-
出口条件
- 各端通过发行前的白盒测试（单元、性能、接口、界面测试等）与黑盒测试，符合在之前文档中定义的各项验收标准，即为发行版本，叫“做好了”。
对于可能的变更是否能制定应急计划?
-
现实情况
- 对于可能的变更我们会提前制定方案，防止出现意外情况，万一出现意外，则和涉及到的人员开启会议沟通，保证及时解决。
员工是否能够有效地处理意料之外的工作请求？
-
现实情况
- 组员在需要修改需求时都会欣然接受，确定具体的修改事宜后开始工作，有效地完成任务。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
-
收获
- 项目的需求不是一尘不变的，需要时时刻刻更新，所以代码的耦合度需要降低，能够适应临时修改的需求。
-
改进
- 如果重来，我们会在开始编码前确定更加细化的规则，为后来的编码提供便利、提高规范性。
part.05 设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
-
现实情况
- 设计工作在系统设计阶段由组长陈浩男参与类图设计、王肃南和关敏撰写系统设计说明书、程伟行设计泳道图和数据流图、黄晓东和郑斯彬负责数据库设计，由擅长该项工作的组员主动提出负责，做起来比较有干劲、有方向。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
-
现实情况
- 三人一同编写的后端因个人代码风格，不规范统一，现已在Beta阶段对后端代码进行重构
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
-
单元测试（unit test）
- 有效，单元测试的创建更简单，维护更容易，并且可以更方便的进行重复，让前后端的代码更加健壮
-
UML
- 因为在实现过程中，设计上的不断改变，最初的UML能起到的作用较小，有必要更新UML文档，为后续的软件迭代更新提供依据
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
-
出现bug的地方
- 前后端交互，在已经编写了接口文档的前提下还是出现了许多接口使用不正确的情况
- 服务器部署，部署花费时间过久，出现了本地服务器测试时未出现的bug
-
原因
- 前后端交互，由于完全线上开发，还是缺乏了一些必要的交流沟通
- 服务器部署，服务器配置过低过卡，使用不熟练，未考虑使用的集成web应用服务器mysql版本的问题
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
-
现实情况
- 由于后端部分是由三个成员编写的，alpha阶段时间比较紧张，所以在beta阶段由专门一个成员负责代码规范的统一；前端由各自负责成员进行复审；前后端基本严格执行了代码规范
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
-
收获
- 还应更加加深成员之间的沟通，不论是更好的统一负责同一类型工作的成员之间，还是分别负责前后端的成员之间
- 还应多学习服务器端搭建的知识，以更好的解决出现的问题
-
改进
- 制定更加细化的开发规范，统一开发；增加会议成员间的沟通交流以及线下的及时反馈
- windows作为服务器还是不规范，学习使用linux平台作为服务器的搭建，更规范
part.06 测试/发布
团队是否有一个测试计划？为什么没有？
-
现实情况
- 因为前后端完全分离，可以前端和后端分别测试，测试分为前端单元测试、性能测试、页面测试；后端API测试、单元测试和性能测试，总体来说是自下而上的测试方法，基本覆盖软件开发需要的测试。
是否进行了正式的验收测试？
-
现实情况
- 我们只做了简单的验收测试，包括界面的验收，后端接口的验收，对应功能是否完善等，在正式发行前，我们将根据之前文档的验收标准进行完整的验收测试
团队是否有测试工具来帮助测试？
前端
-
测试工具选择
- web 前台：chorme 的插件 Frames per second、Component render、Vue.js Devtools v5.0
- web 后台：Jtest、百度云第三方性能测试工具
- Android：Espresso、Junit、LeakCanary
-
测试工具介绍
-
web 前台：
- chorme 的插件 Frames per second、Component render：chorme 的插件，可对 web 前端 js 代码进行单元测试，生成报告与可视化图标
- Vue.js Devtools v5.0：vue 官方性能分析用的插件，可以模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试
-
web 后台：
- Jtest：jest 是 facebook 推出的一款测试框架，集成了 Mocha，chai，jsdom，sinon 等功能。
- 百度云第三方性能测试工具：百度云提供的第三方服务，可对程序进行效能分析生成性能分析报告
-
Android：
- Espresso：Espresso 是谷歌大力推荐的一套测试框架，从 Android studio2.2 版本开始，google 就开始支持在 as 上 espresso 自动生成单元测试代码，Espresso 测试运行速度很快，它允许你在应用程序处于静止时操作和断言等，Espresso 面向那些认为自动化测试是开发声明周期的一部分的开发人员，并且虽然它可以被用作黑盒测试，但是熟悉代码库的人可以解锁 Espresso 的全部功能
- Junit：JUnit 是一个 Java 语言的单元测试框架。它由 Kent Beck 和 Erich Gamma 建立，逐渐成为源于 Kent Beck 的 sUnit 的 xUnit 家族中最为成功的一个。 JUnit 有它自己的 JUnit 扩展生态圈。多数 Java 的开发环境都已经集成了 JUnit 作为单元测试的工具
- LeakCanary：使用 MAT 来分析内存问题，有一些门槛，会有一些难度，并且效率也不是很高，对于一个内存泄漏问题，可能要进行多次排查和对比才能找到问题原因，为了能够简单迅速的发现内存泄漏，Square 公司基于 MAT 开源了 LeakCanary
-
-
测试工具运用
-
web 前台：
- chorme 的插件 Frames per second、Component render：使用 chorme 的插件 Frames per second、Component render 对内部 js 方法单元测试
- Vue.js Devtools v5.0：使用 Vue.js Devtools v5.0 模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试
-
web 后台：
- Jtest：使用 Jtest 对内部 js 方法单元测试
- 百度云第三方性能测试工具：使用百度云第三方性能测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试，生成性能模拟报告
-
Android：
- Espresso：使用 Espresso 对内部对应方法进行单元测试
- Junit：使用 Junit 对内部对应方法进行单元测试
- LeakCanary：使用 LeakCanary 分析内存泄漏
-
后端
-
测试工具选择
- 后端 API 测试：Postman
- 后端单元测试：Junit
- 后端框架（spring boot）单元测试：spring-boot-starter-test
- 后端性能测试：JProfiler
-
测试工具介绍
-
后端 API 测试：
- Postman：Postman 是一款功能强大的发送 HTTP 请求的 工具 ,常用于 web 开发、接口测试,使用非常方便
-
后端单元测试：
- Junit：JUnit 是一个 Java 语言的单元测试框架。它由 Kent Beck 和 Erich Gamma 建立，逐渐成为源于 Kent Beck 的 sUnit 的 xUnit 家族中最为成功的一个。 JUnit 有它自己的 JUnit 扩展生态圈。多数 Java 的开发环境都已经集成了 JUnit 作为单元测试的工具
-
后端框架（spring boot）单元测试：
- spring-boot-starter-test：Spring Boot 集成的 pring-boot-starter-test 是基于 JUnit 的单元测试工具。
-
后端性能测试：
- JProfiler：JProfiler 是一个商业授权的 Java 剖析工具，由 EJ 技术有限公司，针对的 Java EE 和 Java SE 应用程序开发的，可模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试
-
-
测试工具运用
-
后端 API 测试：
- Postman：通过 Postman 对后端编写的所有 http（GETPOST）接口模块进行测试
-
后端单元测试：
- Junit：通过 Junit 对后端工具类对应方法进行测试
-
后端框架（spring boot）单元测试：
- spring-boot-starter-test：通过 spring boot 的测试模块（spring-boot-starter-test 基于 junit）对后端框架（spring boot）的服务层进行单元测试
-
后端性能测试：
- JProfiler：使用 JProfiler 模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试
-
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
-
现实情况
- 前后端均有使用对应工具对软件的性能进行测试，压力测试将在Beta阶段同期进行，并一同完成请求队列等优化减缓并发压力，从目前来看这些测试工作有用，应改进进行覆盖面更广的测试
在发布的过程中发现了哪些意外问题？
-
现实情况
- 在代码部署到服务器上时由于服务器和本地环境不一致出现了些问题，在修改了数据库的版本问题后成功发布
我们学到了什么? 如果重来一遍, 我们会做什么改进?
-
收获
- 测试是一项枯燥、但是非常有必要的软件开发的一个过程，可以在软件出现bug时快速排错，提高修复效率。
-
改进
- 如果重来一遍，我们会多留出一两天的时间给测试，这次冲刺中低估了测试需要的时间导致在即将结束时匆忙测试，测试相对流于表面、不够全面。应该在测试的边界问题、测试的全面性上多下功夫。
part.07 团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
-
现实情况
- 首先前后端的分工是由组员自愿的，因为在组队时有考虑到分工的问题，所以现在的组员是能够在自愿的情况下完成一个项目，每个人都能担任想要的角色，提升自己对应位置的工程能力，做到人尽其才，各有所得。
团队成员之间有互相帮助么？
-
现实情况
- 因为组员是合作过多次的老队友，所以在遇到问题时我们不会吝啬自己的言语、提出自己的疑问，同时需要帮助时也会尽力提供，帮助完成任务。如前后端在冲刺期间如果遇到问题会在站立式会议提出，大家可以一起给出建议（其实都是一个专业或多或少都会点，只是每人在哪方面更擅长的问题），有时往往问题能在多人讨论中被提出后轻松解决，其实也和“小黄鸭调试法”一样，当你在多人讨论时把程序的调试、纠错或测试过程中，耐心地向所有人解释每一行程序的作用，自然灵感也来了。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
-
现实情况
- 目前为止在项目管理上基本未出现问题，项目管理应该是本小组做的相对比较不错的一部分，有在线文档（如接口文档、前端反馈文档用于前后端交互，每日冲刺汇总用在线文档，每日会议记录在线文档等），teambition用作项目管理，qq群作为讨论及发布公告，腾讯会议进行站立式会议；合作方面，如有疑问会直接提问对应工作的负责人（比如对于前后端交互，后端就专门有设一位成员解答前端疑问），直接解决问题，谁出现问题谁修改，直至达成统一意见。
part.08 总结
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
-
代码管理的质量
- 代码管理本次是通过一位成员来统一规范，修改不同规范处的代码，来达到一致
-
代码复审和代码规范的质量
- 代码复审的质量则取决于规范代码的成员的水平，当然会由其他成员再次复审，提出需要修改的地方再复工。
整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
-
程序的架构提高
- 最基本的面向对象设计：整体程序的架构是高内聚，低耦合的；软件的实体应对拓展开放，对修改关闭；复用的子类型应在任何场景都能替换父类型；面向接口编程；优先使用聚合或合成关系复用代码；接口使用小而专
- 业务（逻辑）架构的提升：：使用一套方法论对产品（项目）所涉及到的需求的业务进行业务边界划分，简单的讲就是根据一套逻辑思路进行业务的拆分，总体原则是对业务进行业务边界的划分，比如做专属网站，需要把对应的细节功能清晰的划分出来，而业务架构不需要考虑诸如我用什么技术开发、我的并发大怎么办、选择什么样的硬件等等
- 应用架构的提升：应用是介于业务语言与技术语言之间，是对整个系统实现的总体上的架构，需要指出系统的层次、系统开发的原则、系统各个层次的应用服务，例如，上述系统中可以分为、数据层（资源层）、数据服务层、中间构建服务层、业务逻辑层、表现层，并写明每个层次应用服务
- 数据（持久化）架构的提升：对存储数据（资源）的架构方法论，其架构原则同应用架构大同小异，即考虑到各个系统应用场景、不同时间段的应用场景对数据进行诸如数据异构、读写分离、数据库或NOSQL的策略、缓存的使用、分布式数据（数据库）策略等等
- 技术架构的提升：对上述架构中提出的功能（或服务）进行技术方案的实现的完成与优化，包括软件系统实现、操作系统选择、运行时设计。提升技术架构时的设计面，提升专业性
-
质量的提高的衡量
- 底层代码性能的明显提升，占用内存、运行速度等性能指标的提高；用户体验反馈的明显提高；系统的负载能力等的上升
其它软件工具的应用，应该如何提高？
-
现实情况
- 几种测试工具的使用，以及项目管理软件工具，文档编写工具，美工工具等的使用的提高，就遵循一句话——熟能生巧，多学多用，多看别人优秀的作品，取其精华，去其糟粕，拥有他人优点的同时发挥自己的建树，站在巨人肩膀上看问题，自然也就提高了
项目管理有哪些具体的提高？
-
现实情况
- 站立式会议第一天分工后成员量化各自的任务，然后在teambition上分配任务，每日拖动完成的任务，来展示项目的完成进度，分工明确，同时量化细致，可以以此来分配成员的贡献度。
项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
-
用户数据方面
- 在线活跃用户的数据统计，用户反馈调查（问卷、功能入口等），系统数据变化统计（上传、发布等）
-
获取方法
- 前端反馈收集在线用户，问卷、软件内部入口收集反馈信息，数据库获取最近活跃新插入数据等
项目文档的质量如何提高？
-
现实情况
- 一方面是细化任务，更加具体，才能有更高的质量，另一方面是多观摩别人的文档，吸取经验。
对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
-
现实情况
- 要有适当的奖惩机制，例如每日工作在规定时间内未汇报的则给予适当的（全部成员一致同意的）惩罚，提早完成分内工作的则给予奖赏。在调动成员的工作积极性方面，仍有提升的空间。
对于软件工程的理论，规律有什么心得体会或不同意见？
-
心得体会
- 在文档编写上，如果是团队一起负责编写，那么文档格式一定要提前规定完整，这样最后的整合也将避免过多的修改，占用过多时间
- 在代码需要去网上借鉴时，不能一味地抄袭，因为有时候拷贝下面的代码，还需要有一定的扩展，在代码规范上也不一定符合该项目的要求，需要合理并且规范地使用
part.09 成员交接相关
221701428 许光清（新组员）
旧组工作：
负责产品经理相对应工作；在alpha版冲刺中对项目进行了初步的测试工作
工作交接：
利用QQ聊天方式进行交流，由于并不进行旧组项目的代码开发工作，因此无需太多的交接过程
新组适应计划：
为快速融入新团队，和队长以及队员及时了解项目目前的完成情况和对下一阶段的冲刺目标，并对项目提出一些可行性建议和想法；在旧组中不负责代码开发，在新组中希望可以接手部分测试工作；新组队员都是本班同学因此适应过程比较愉快，希望接下来的阶段为项目做出贡献，积极推进项目的开发进展
221701412 陈浩男（组长）
为新组员安排的角色：
本次换组迎来的是自己班级的另一位同学，大家也是比较熟悉的，在和其进行交流沟通后，得知他比较意向的角色是测试工作，正好之前团队的测试工作并没有专员进行，是由开发人员顺带负责的。所以安排新组员作为测试人员加入团队一同进行开发。
自己是如何面对之前的成员离开队伍的：
在换组进行之前，我们小组的项目的基本功能已在上一阶段大致完成，与我们在之前那么多次一起征战的队友离队确实是很不舍的，但就事实而言，我们小组无论是我还是其他的任何一位成员被进行了调换都不会太大的影响整体的开发进度，希望新组员能尽快融入队伍，走了的老队友也依然能在其他小组大放异彩，加油！
具体做了哪些措施，是否有调整开发计划，开发计划调整了哪些部分？
由于新组员是本班同学，就省去了为其他成员介绍的工作，大家都比较熟悉，组内的成员也在第一时间了解到了来到的新成员是谁。对于开发计划的调整，根据新成员到意愿，将测试工作从原本的开发人员负责调整为了新成员专门负责。
组长为新成员安排的任务：
- 1、继续学习测试相关知识，增加往后测试的覆盖面的广度与宽度
- 2、加入本组的Gitub组织，拉取小组的合作仓库（代码、代码规范及一直以来的团队文档），了解项目的整体系统设计
- 3、多与小组成员交流，不懂就问，本班的同学不致于会害羞吧？～笑
换组事项的感想和收获
221701428 许光清（新组员）
换组其实还蛮有意思的，随遇而安嘛，在进组不久后确确实实的感受到了旗山的骄傲小组是相当个优秀的小组，希望接下来的阶段为项目做出贡献，积极推进项目的开发进展
221701412 陈浩男（组长）
不论是在现在还是未来工作的开发中，一个团队出现人员调动是很正常的一件事情，一个真正优秀的团队也不应该被成员的调动而影响到，适应以最快的速度继续投入到接下来的工作才是该干的事情。正如我认为的我们小组无论是我还是其他的任何一位成员被进行了调换都不会太大的影响整体的开发进度，希望新组员能尽快融入队伍，走了的老队友也依然能在其他小组大放异彩，加油！