MachineGuard机房捍卫者——Beta冲刺总结随笔

222000321熊中伟学生 2023-06-02 23:59:21

这个作业属于哪个课程	2023软工W班
这个作业要求在哪里	https://bbs.csdn.net/topics/615412167
团队名称	Machine Guard
这个作业的目标	Beta冲刺总结随笔
其他参考文献	无

1 项目任务完成情况
2 团队改进完成情况
3 上线链接
4 项目成果
4.1 用户系统、鉴权控制
4.1.0 主页
4.1.1 登录
4.1.2 权限控制
4.2 监控模块
4.2.1 楼层总体视图
4.2.2 单一楼层视图
4.2.3 机房页面
4.2.4 机房设备视图
4.2.5 机房设备控制
4.2.6 机房预警、抓拍以及运行信息.
4.2.7 机房监控流
4.3 日志模块
4.3.1 设备日志
4.3.2 机房日志
4.3.3 警报日志
4.3.4 日志筛选
4.4 统计模块
4.4.1 当前状态
4.4.2 警报统计
4.4.3 温度湿度统计
4.4.4 设备状态统计
4.5 用户和管理员控制模块
4.5.1 最高管理员
4.5.2 普通用户
5 团队分工协作
5.1 成员工作
222000322
222000231
222000310
222000317
222000309
222000234
222000321
222000320
5.2 贡献度
6 成员心得感想
6.1 222000321
6.2 222000234
6.3 222000231
6.4 222000320
6.5 222000322
6.6 222000317
6.7 222000309
6.8 222000310
附录 Alpha、Beta冲刺问题回答
Alpha冲刺
Beta冲刺

1 项目任务完成情况

计划任务	完成情况	完成度
实现基于CV的监控自动抓拍和警报触发	训练了基于openCV的目标检测模型，并设计了触发器，当目标活动达到一定阈值时能够自动地发送警报日志，并且将抓拍照片发送到COS。目前这个功能是已经完成并上线的，但是问题在于受限于数据集，没能训练到一个比较高质量的模型，人体在角度比较偏的时候会检测不到。此外，火焰模型受制于干扰因素比较多，以及时间等考量没有加入到最开始的计划中去。	80%
实现基于ML的温度预测	已经完成了基于SVM的温度预测功能。因为我们的训练数据比较少，用神经网络发现欠拟合，因此另外选用SVM来训练。因为机房总体来说温度起伏规律比较一般，最后的拟合效果比较好，基本达到了预期。	100%
完善前端输入逻辑，保证正确反馈错误信息给用户，实现前后端数据双重验证	前端的同学对用户输入和用户反馈做了优化，保证出错会通过顶部弹框的形式反馈给用户，而不会出现点击内容之后既没有响应和没有报错的情况。	100%
完善通知逻辑，实现用户可实时接收到重要警报信息	新加了一个通知模块，对于一些突发、即时的警报日志，会被同时发送给这个机房的管理员一条短信。这个功能是依托腾讯云实现的，目前已经上线。	100%
自由化机房模型，使得设备可以被自由增添、放置在机房的任意位置，其设备的形状大小等也可发生改变	在自由化机房模型上，我们修改了后端的实体表，使得它可以记录机房和设备的具体位置和规格。在前端模型渲染上，我们使用了偏移思想来实现一种带限制的模型自由化。只要填写好参数，机房可以改变其在一层楼的位置以及长度，这样可以解决部分机房横跨多间房间的问题。设备的自由化同理，这样可以支持一些非常规位置的设备，比如悬挂式设备。同时对模型的一些细节进行了优化。	100%
完善机房和设备的修改逻辑	在自由化模型的基础上对机房和设备的增加和修改逻辑进行了完善，可以选择在增加和修改机房的时候同时设置机房的规格和位置及参数。同时对一些控制逻辑进行了优化。	100%
精化建模，增加贴图等加强仿真的视觉效果	实现了机房设备的建模贴图，但是由于素材受限，效果不是很理想，可能还需要另外找更好看的贴图素材，以及对整个机房都进行贴图的完善。	80%
为日志等模块增加更加丰富的筛选器	增加了一个带模糊搜索的日志筛选器，能够实现对日志记录message的关键词进行模糊搜索。同时对每一张表都实现了状态字段和时间字段的排序和筛选器，可以直接通过表头来筛选数据。	100%

2 团队改进完成情况

单独增设测试岗位2位，不再是后端同时兼任测试的工作

本次新增222000309、222000231同学为后端进行测试。这两位同学在队内的alpha冲刺岗位为java后端，除了在beta冲刺中完善一些自己在alpha冲刺的代码外（新加入同学没有这个安排），还独立为其他新的接口和更改的接口进行测试功能，完成测试报告。

事实上，这比让后端在完成业务代码的同时进行测试更加能够发现bug，并且让团队整体的工作效率提升。

下面是部分测试文档。

设置动态分工方法。为了预防新人在实际工作时可能的任务延后情况，将其工作责任动态分配。

原先的成员在小组内主要的工作职责是java后端的部分接口以及少部分的测试工作。这部分的开发内容在alpha阶段已经完成，剩余的是一些可能的补缺补漏以及bug的修复工作，加之现在加入的新成员技术栈与原先的一致，因此并不会带来特别多的重新学习成本，没有特别安排工作计划的调整。

考虑到新成员在beta冲刺中如果遇到一些修补工作时，可能会带来的计划延缓，保留了一个备用方案，在day1-day3需要该成员进行修复的模块由后端负责人与其共同开发。这样能够解决可能造成的进度延缓。

之前的成员留下了大量的文档和代码素材，包括：接口文档、测试文档和后端模块代码。这部分的内容都已经准备好可以转交给新组员。
使用teambition作为团队项目工具，而不是简单的共享表单

本次团队管理使用了阿里的teambition。在teambition中，我们创建了一个团队，然后创建了一个项目。在这个项目中可以新建任务并将其指派给某个负责的同学，这解决了任务下发到具体的人的问题。

同时，项目还可以建立多种状态。如果后期发现项目出现问题，比如测试同学发现接口有bug，这个时候就可以将状态置为“待修复”。这样就方便后端的同学发现并处理。

接口管理软件规定对接口的限制，包括格式，内容和路由约束。

额外在接口管理软件中约束了接口的限制，特别规定了返回的格式，这样同时也能给测试人员提供指引。

3 上线链接

https://mg.markpolo.cn/

4 项目成果

4.1 用户系统、鉴权控制

4.1.0 主页

用户进入页面之后，首先进入的是主页。主页介绍了项目的基本信息，可以通过这个页面的顶部的导航栏进入具体的模块。

4.1.1 登录

首次使用系统的用户进入任意一个模块都会跳转到登录页面。登录可以使用账户名密码登录，也可以使用手机号验证码登录。必须首先选择普通用户和管理员，获取全局的权限状态。

4.1.2 权限控制

系统基于JWT实现鉴权。前端登录之后JWT有效期为7天，过期后将自动放弃JWT；用户也可以主动退出登录，退出登录时JWT失效（视为过期）。

4.2 监控模块

位于其他模块时点击左侧导航栏，或者在home界面时点击上方的监控导航栏，将跳转到监控模块。首次登录后也将跳转到登录模块。

监控有一个次级导航栏用于定位到某一个楼层，或者用于在总体视图和单一视图之间切换。

4.2.1 楼层总体视图

楼层整体视图用于3D建模展示机房在整栋楼中的分布情况，方便用户能够直观地定位到自己想要的机房。每个机房上标有机房所在的楼层和机房名称。目前增加了对空楼层的展示，以及机房的自由化，可以使得机房偏移原位置，也可以让机房变长。

默认地，监控模块的入口视图是楼层总体视图。如果在从其他视图到要切换到总体视图，需要在次级导航栏选择ALL选项卡。

在楼层总体视图，用户可以右键拖动模型进行模型平移，可以滚动滚轮进行模型放缩，也可以左键点击某个机房直接将视角转移到对应机房的正前方。

左键双击某个机房将跳转到对应机房的页面。

右击左侧的楼层选择器能够进行机房的新建。

4.2.2 单一楼层视图

单一楼层视图用于3D建模展示机房在某层楼中的分布情况，方便用户能够直观地定位到自己想要的机房。每个机房上标有机房名称以及一些基本的环境信息（温度和湿度）。

当用户点击左侧次级导航栏的对应楼层时，跳转到对应楼层的单一楼层视图，跳转之后默认定位到从左至右第一间机房正前方。

用户鼠标操作交互与楼层总体楼层视图一致。

如果某层没有机房，会弹出提示：

4.2.3 机房页面

机房页面用于展示某间的机房的设备布局模型、环境信息、监控报警信息、抓拍记录以及监控视频，同时是设备视图的入口。（图中左侧因长截图导致异常请忽略）

4.2.4 机房设备视图

机房设备视图用于3D建模展示一间机房内设备以及其他构成的分布情况，便于用户定位到想要操作的设备。目前，机房设备视图也支持长度的自由化。设备也可以放在机房的任意位置。

在楼层总体视图，用户可以右键拖动模型进行模型平移，可以滚动滚轮进行模型放缩，可以左键拖动模型进行模型旋转。其中透明度较高的实体为机房，透明度较低的为机房设备。黑色实体为通道或门。左键双击某个设备将展开机房设备控制面板。

新增了设备的贴图。

同时，可以点击room名右边的按钮，修改当前机房的信息。

4.2.5 机房设备控制

左键双击某个设备将展开机房设备控制面板。展开后可以看到设备详细信息，包括：

设备名
设备状态
设备状态控制开关
温度预测折线图
日志列表
编辑入口按钮
设备CPU占用率
设备网络IO
设备硬盘IO

其中，点击Temperature Prediction显示温度预测。

点击View Log显示日志。

点击Edit Device编辑当前设备。

左键双击其他空白区域关闭面板。

在空闲时双击空白区域新增设备。

4.2.6 机房预警、抓拍以及运行信息.

机房传感器采集的数据：温度、湿度、运行状态将显示在机房设备视图左侧。

机房安全警报简讯将显示在Alarm Data区域。

机房抓拍的图片将显示在Surveillance Capture模块。

点击这个模块来显示最近10条抓拍照片。

4.2.7 机房监控流

返回实时监控流。

4.3 日志模块

位于其他模块时点击左侧导航栏，或者在home界面时点击上方的日志导航栏，将跳转到日志模块。

4.3.1 设备日志

用户可以点击左侧次级导航栏Device选项卡的任意设备进入设备状态日志。

4.3.2 机房日志

用户可以点击左侧次级导航栏Floor选项卡的任意楼层进入该楼层内的机房的状态日志。

4.3.3 警报日志

用户可以点击左侧次级导航栏Alarm选项卡的任意类型警报进入该种类型的警报日志。

4.3.4 日志筛选

在任意的日志筛选模块中，上方的搜索框可以键入关键词，对message、type进行模糊搜索。

同时，在表格的表头也实现了列的排序和筛选功能。

4.4 统计模块

位于其他模块时点击左侧导航栏，或者在home界面时点击上方的统计导航栏，将跳转到统计模块。该模块使用数据可视化图表形式展现了数据以及数据的变化。点击左侧次级导航栏可以快速滚动到对应的子模块。

通过上方的二级下拉框可以选择要展示的机房。

4.4.1 当前状态

主要以仪表盘的形式展现了机房的基本环境数据（温湿度），以及机房内每个设备的工作数据（CPU占用率、IO等）。可以通过下拉选框选择使用哪个设备。

4.4.2 警报统计

以散点图展示了该机房最近7天内各类警报的个数；以饼图的形式展示了各类警报的占比分布情况。

4.4.3 温度湿度统计

以折线面积图的形式展示了该机房昨天0点至24点的温度变化情况；以饼图的形式展示了该机房温度情况的大致分布。

4.4.4 设备状态统计

以折线面积图以及柱状图的形式展示了该机房内设备某天0点至24点的设备信息变化情况，包括：

复合折线图展示设备上传下载速率
折线图展示设备cpu使用率
柱状图展示设备运行和停止的小时数
复合折线图展示设备IO读写速率

其中，鼠标移至折线图上方可以查看该时刻的具体数值。

可以通过两个下拉选框选择要展示的设备和日期。

4.5 用户和管理员控制模块

位于其他模块时点击左侧下方的人像符号将跳转到用户和管理员控制模块。该模块提供给管理员，用于控制全体用户的独立权限。

4.5.1 最高管理员

最高管理员是可以控制其他用户权限的管理员，在列表中用绿色的标签标注。仅能查看其基本信息，不能为其额外分配或删除权限。

4.5.2 普通用户

普通用户接受来自最高管理员的权限分配，使得普通用户能够成为一些机房的管理员，对这些机房进行设备操作。

5 团队分工协作

5.1 成员工作

222000322

机房和设备实体的字段添加，并在业务逻辑中适配
机房抓拍接收接口
接口规范设计
短信通知功能接入

222000231

优化代码结构
调整设备组和机房组的接口，以适配设备和机房表的变动

222000310

前端添加日期筛选器
前端添加搜索器
前端业务逻辑请求适配

222000317

新增日志-抓拍映射（表）
设计前端通过日志获取抓拍到的照片的接口

222000309

对beta测试新增以及修改的接口进行测试
生成测试文档

222000234

优化统计模块样式，响应式适配
优化统计模块代码风格

222000321

CV目标检测模型训练和部署
CV目标触发单元设计，实现抓拍事件触发时给后端发请求
基于SVM模型的温度预测模型训练和部署
前端的模型构造器适配自由化渲染需求

222000320

完善测试文档
撰写博客和相关文档

5.2 贡献度

学号	工作量/贡献度
222000321	14%
222000234	12%
222000231	12%
222000320	3%
222000322	18%
222000317	15%
222000309	12%
222000310	14%

6 成员心得感想

6.1 222000321

在最后的beta冲刺阶段，我主要是负责统筹项目，发布和确定实际需求并适时修改，跟踪进度，组织站立式会议和线上会议，项目质量控制，检查各成员代码和发布流程符合规范。同时我还参与了前段机房和设备的自由化工程，以及训练了CV模型，实现对应功能。

在本次的beta冲刺中，有新的成员加入。作为组长，对我来说还是一个不小的挑战，因为原先的成员的职责包括测试工作，而新转来的组员没有测试经历，这需要学习的时间。但是好在之前的成员留下了不少文档，而且转入和转出的成员岗位技术方向一致，相对来说节省了一些时间成本。对于组长来说，做好beta冲刺之前的磨合工作尤为重要，因为在这段还未进行实际开发的时间，就可以用来进行项目的交接和新技术的学习。这段经历让我收获了人员变动时项目团队管理的新的经验。

此外，对团队管理的优化也让我感觉眼前一亮。我们在beta冲刺使用了teambition，这比我们过去使用在线表单来核对进展来开展团队协作更加清晰高效。之后我也将学习更多的专业的团队管理软件。

很高兴和团队其他成员完成了全部的组队任务。一路上我收获颇丰，在团队管理，软件工程和开发等领域都有了一些进步。

6.2 222000234

个人工作内容

在beta冲刺阶段，我优化了前端统计模块数据可视化界面的样式，完成了该页面的响应式适配。同时优化了我的代码风格，使代码更符合规范、清晰易读。

冲刺收获

学习了前端响应式适配的相关内容，对流式布局的响应式技巧有了更深的掌握，如百分比布局、弹性盒、弹性网格\浮动技巧等。
对代码规范的意义和重要性有了更多认知，一个规范的代码能够极大地方便编程时的错误调试、后期维护和修改以及团队协作

合作情况

在beta冲刺阶段，我们的队长也同样制定了清晰详细的计划，分配了具体任务给大家。我的队友们仍然保持互相帮助、富有责任感、积极沟通的态度。大家都在为一个目标努力，合作起来协调一致，我们小组是很棒的团队！

心得体会

随着团队项目的告一段落，代表着软工实践课程的尾声。就我个人而言，在团队作业中我的收获是最大的，我的进步体现在编程能力、代码管理、沟通协作各个方面。感谢软工实践这门课程，我受益匪浅，在未来我一定继续努力、不断实践、挑战自己。

6.3 222000231

一、个人任务

在这次团队实践的过程中，我主要完成了对α冲刺所写的代码的优化，并对团队新增的接口进行了测试。

1.优化项目结构，删除冗余代码。

2.调整设备组和机房组的接口，以适配设备和机房表的变动。

3.对新增的日志图像接口进行测试工作

二、阶段收获

学会了如何进行scrum敏捷项目开发，切身实地体验了一个项目从提出到开发、测试、上线，既锻炼了我的开发能力和团队协作能力，也让我对软件工程这门学科有了更深的认识。

三、合作情况

在本次β冲刺中，我们的团队迎来了一位新队员；因为我们在α冲刺中就完成了大部分模块的开发工作，所以后续的开发上并没有遇到很难磨合或者是有重要工作未完成的情况
总体来说，经过前几次团队作业，我们大家都挺默契的，各司其职，然后谨听队长的指挥。感觉我们的团队还是很团结的，大家都很靠谱。

四、心得体会

这次β冲刺其实我的工作量不大，主要是做一些收尾的完善工作。对比起极限编程的兵荒马乱，这次项目的开发可以说是细水长流，看来团队大纲和每天一次的冲刺会议真的很有用。在软工实践这门课中，我锻炼了自己的开发能力，确定了自己未来想要从事的方向，还学会了如何做团队中的一颗“螺丝钉”，掌握了和队友进行沟通交流的艺术，对我以后的工作应该会有很大帮助。

6.4 222000320

在beta冲刺阶段，我的任务是每天总结小组里的任务，并将其撰写成一篇博客，同时我也负责参与了一部分的测试工作。在测试的过程中，我需要不断学习和调整测试策略，测试还需要与其他小组成员的工作密切配合，以确保整个项目的顺利进行。在项目中，我还学习了许多关于软件工程方面的知识。除此之外，与小组成员合作和沟通也是我在这个项目中的重要收获。团队合作和沟通是项目成功的关键要素。在项目中，我们需要互相协作，相互支持和尊重，以达到项目的共同目标。在和小组成员的交流和合作中，我深刻体会到了沟通的重要性，不仅要求自己能够表达清晰，更需要认真聆听和理解他人的意见和想法。通过这十天的学习和实践，我得到了许多宝贵的经验和体会。我们需要不断学习和更新自己的知识和技能，同时也需要与小组成员建立良好的合作和沟通关系。

6.5 222000322

一、个人任务

在本次β冲刺阶段团队作业中，主要针对α冲刺遗留下来的接口进行完善和开发：

1.根据业务需求，修改了机房和设备表的字段并对相应的类进行了修改完善。

2.完善了短信发送接口，从只能向单一手机号发送短信变为可以同时向多个手机发送短信。

3.修改了机房和设备添加接口的业务逻辑。

二、阶段收获

加深了对腾讯云短信服务SDK的使用理解

三、合作情况

在本次β冲刺中，由于团队成员发生了变动，在新旧队员任务交接的过程中，不可避免的出现了一些问题，比如老队员没有把自己手头的全部资料转交给新成员，以至于新成员不知道如何继续工作，只能来问组内的其他成员，但其他成员对老成员的工作也并不熟悉，这在一定程度上延缓了项目的进展，但好在我们及时发现问题并完成了交接工作，新成员顺利接手并完成了遗留下来的任务。

由于有了α冲刺阶段的磨合，在本次的β冲刺中与小组原成员的合作十分丝滑顺利，大家默契十足，干劲满满，顺利完成开发任务。

四、心得体会

本次β冲刺阶段的结束也意味着团队项目的结束。回顾这段说长不长，说短也不短的团队合作时光，我认为我收获了许多。我学会了如何使用git进行版本控制，接触到了RTSP视频推流，了解到了Rocket MQ消息队列以及docker容器部署等方面的知识（虽然有些由于时间以及技术上的原因被阉割了，但也算增长了知识面）。这一系列的体验使得我对后端开发的技术栈以及中间件有了更加全面的认知和了解。

除了获得了开发方面的经验，本次α以及β两轮冲刺使我更加了解软件的开发流程，也经受了组员流动所带来的的考验，我认为这些都是十分珍贵的经验。

6.6 222000317

在参与软件工程beta冲刺过程中，我的工作主要涉及到新增日志-抓拍映射表、设计前端通过日志获取抓拍到的图片的接口以及丰富日志筛选器的后端部分。在这个过程中，我深刻认识到了团队合作的重要性，并与团队成员紧密合作，一起进行需求分析和代码实现。通过积极地与其他成员交流，我更好地理解并且遵守了项目的开发规约和流程。在完成接口实现的过程中，我和其他团队成员进行了积极的协作，共同解决了接口实现时的一些问题，这使整个项目开发过程更加顺畅。

在这个过程中，我对于workbench的一些常规操作更加了解和熟悉了，并且深入掌握了接口的开发。对于个人能力的提高和团队协作的重要性有更深层次的认识。同时，我也更加清晰地认识到了软件工程开发的重要性以及如何更好地完成一项软件工程开发任务。

总的来说，参与软件工程beta冲刺是一个很有收获的过程。在这个过程中，我不但提高了自己的技能水平，更加清晰地认识到了团队协作的重要性，以及如何在一个团队中高效地完成一个软件工程开发项目。

6.7 222000309

个人任务：

对β测试新增以及修改的接口进行测试，并生成测试文档

阶段收获：

学习了如何系统地使用Apifox来进行接口测试。
学会了如何使用junit进行单元测试以及如何使用Apifox进行性能测试
锻炼了快速融入新团体的能力

合作情况：

在团队交接的过程中，不可避免的要和其他组员进行交流沟通来确定自己在组内的工作。因为，我原本在团队中是负责后端接口的开发，所以对系统的接口测试这一方面并不是特别熟悉。好在群里有前面一位同学遗留下来的每日冲刺和工作总结文档，再通过询问其他成员，我最终才能够接手并完成前面一位同学遗留下来的任务。

心得体会：

对于自己被抽中换组以后，心情一开始是忐忑惶恐的。一方面，对于离开熟悉的环境和熟悉的队友，内心不免会有些焦虑；另一方面，又担心自己加入了新的队伍会跟不上其他人的进度，给小组凭添麻烦。好在组长给了我一定的缓冲期，并耐心地给予了我很多帮助，队友也替我分担了不少任务，这才让我顺利地接替了前面一位同学接下来的测试工作。在β冲刺阶段，大家的工作其实都已经大体上有了成熟的框架，所以我做的工作基本上都是基于他人的基础上来进行的；更多的是来学习和参观别人的项目成果，拓宽自己的眼界并锻炼自己快速融入新环境的能力，就此而言，这段经历对我受益匪浅。

6.8 222000310

个人工作内容

依据任务安排, 完成前端日志模块中的展示内容优化
完成前端日志内容中的日期筛选器
完成前端日志内容中的内容模糊搜索
完成前端业务逻辑请求适配

冲刺收获

掌握了ElementPlus现有组件的使用, 大大提高了开发的效率
对JS的使用进行了巩固与复习, 对其中的知识进行了进一步的深入了解
对TS进行了部分学习, 了解了TS类型声明的操作以及相较于JS的新特性
明白了团队分工协作的重要性

合作情况

通过git仓库统一管理代码开发
由每日的站立式会议来总结昨日所遇困难并总结不足,对今日工作安排做出细致划分
在遇到开发问题时通过QQ在线聊天软件做出及时的交流沟通

心得体会

本次β冲刺在α冲刺的基础上进行开发, 由于α冲刺安排较为妥当, 大致的功能需求都已完成, 大大减轻了β冲刺的工作量,并且在先前已经建立好的合作基础上, 在总体开发过程中称得上是得心应手。我深知目前这个项目离成为企业级软件的目标还相差甚远，但不管怎么说，本次的团队项目开发也是对企业软件团队开发流程做出了一次简单模拟。通过两次冲刺，我对于软件开发的流程有了更为细致的了解，对于如何进行团队之间的磨合以及工作任务细粒度的合理分配也有了更深层次的把握，在冲刺过程中发现并认识自己的不足，并加以矫正，能够发现自己编程的弱项以及不好的开发习惯，这些在我看来都是我在这次冲刺过程中所收获的内容。在今后我会努力改正自身存在的缺点，向成为一名拥有高素养的程序猿的目标不断前行。

附录 Alpha、Beta冲刺问题回答

Alpha冲刺

虽然任务落实到个人，但是进展安排还显得粗放，Beta阶段希望能够进一步精细。

是的，我们的分工还没有那么精细。在beta阶段我们将尝试使用teambition等团队工具来解决这个问题。
如果组员无法胜任工作，何时将任务转移到其他组员？

一般来说，我们给成员分配的岗位和职责都是对口的，也提前告知了需要用到的技术。如果说组员不能完成某个任务，一般是因为在某个技术点上卡住了。这时我们会先选择叫其他成员来协助，如果确实无法解决就会交给这个岗位方向的负责人同学完成。
接口能够随意更改吗？是否有一定的规则约束？

接口有一定的约束规则，这主要基于行业的惯例，比如API接口的restful，但是这种约束比较宽松，会带来一些不一致。在beta冲刺中我们会加强对接口的限制。

Beta冲刺

你认为Beta冲刺与Alpha冲刺最大的创新点在哪里？

Beta冲刺引入了自由化机房和设备的概念，使得其定义的粒度变小，更好地满足机房监控用户对机房仿真和设备仿真的需要。
你认为使用Teambition工具对项目管理最大的好处在哪里？

1.精细化，在teambition中可以为每个任务设置子任务，每个子任务都能分配到不同的人，使得项目的工作分配变得精细化；2.直观，所有的不同状态的任务都放在看板上，哪些任务已经完成，哪些任务未完成还剩多少，哪些任务被测试打回需要返工，这些都很清晰。
你们两次测试组织的方式不同，是否印证独立测试岗位的优越性？

是的。在alpha冲刺中，我们使用了交叉测试。在这种测试方法中，后端同学自己充当测试，但是测试的是别人的接口。而在beta冲刺中，我们单独新增测试岗位，每当后端完成一个接口之后测试同学就会进行测试，并将测试情况报告在teambition中。这样的好处是测试的同学可以更专注于测试样例本身，而不需要考虑代码细节。

...全文