记一次敏捷迭代中软件实现的过程
项目背景：敏捷开发，迭代周期为两周，US即我们常说的需求；
本次迭代中主要的US主要为：机器人的路径在web端显示任务；以下为该US主要的实现的步骤；
1、系统需求
2、系统需求的评审
3、开发写系统实现
3.1、开发写系统实现-通信机制（MQTT）topic字段定义——该页面特殊点的接口主要就是状态信息的推送和位置信息的推送，
关于该需求整个结构是前段——服务端——机器人，机器人与服务端的通讯机制统一使用MQTT，前段和服务端的通讯机制：主要是HTTP协议、websocket、MQTT；
最开始的关于信息变化的采用的以下几种方式：
a、最开始使用的HTTP请求，前段设置定时器去刷新，使用http最大的弱点就是：请求-响应机制，只有前段发起了请求，后端才会进行响应；
b、然后就是改造为websocket通信方式，一直处于长连接状态，可以减少系统资源的消耗：带宽；但是有个问题就是浏览器的页面有websocket连接数量限制，而且对于一个页面
上存在变化的消息比较多，会使用到多个websocket连接，例如在现在这个项目上的A页面，有位置信息、状态信息、电梯信息、告警数量统计，该三种信息是不能放在同一个websocket里面的，
就得建立三个websocket连接；
IE 6个
chrome 256个
Firefox 200个
safari 1273个（MAC版本）
c 、最后通讯协议就定义为MQTT协议，在一个websocket连接的基础上，订阅多个topic，该实现的类似方式和mqtt.fx客户端工具，mqtt.fx客户端建立的是tcp连接上实现的多topic机制。
最后采用的mqtt的机制有同步机制改为了异步机制，关于这一点一直没有搞懂，虽然同步、异步没有任何好坏之分，主要看使用的不同场景；topic格式如下：
服务发布Topic的格式：/cloud/web/${业务模块}/${设备ID}/${消息类型}/${方式}
- 推送机器人状态信息Topic： /cloud/web/device/${设备ID}/status/push
- 推送机器人位置信息Topic： /cloud/web/device/${设备ID}/position/push
- 推送电梯运行信息Topic： /cloud/web/elevator/${电梯设备ID}/state/push
3.2、前后端定义接口文档
1.根据省、市、小区查询楼层信息（已经实现） URL：get请求 http://{ip}:(port)/robot/organization/organizationSimple 2.根据楼层的组织ID查询地图列表（已经实现） URL：get请求 http://{ip}:(port)/robot/map/mapFloorList/{organizationId} 3.根据mapId查询该地图ID上的机器人列表（新开发） 机器人信息包括：设备ID、设备名称、设备类型、剩余电量、清水箱状态、污水箱状态、任务状态、任务进度 URL：get请求 http://{ip}:(port)/robot/device/getRobotByMapId/{mapId} 4.根据设备ID查询机器人当天作业轨迹（新开发） 运动轨迹信息包括：设备ID、地图ID、坐标点（格栅坐标和角度），返回的点数据按照上报时间排序 URL：post请求 http://{ip}:(port)/robot/device/historyPositions 5.根据organizationId查询该组织ID上的电梯信息列表（新开发） 电梯信息包括：电梯设备ID、轿厢信息 URL：get请求 http://{ip}:(port)/robot/elevator/listByOrgId/{organizationId
3.3、系统实现接口时序图或者叫活动图
3.4、位置信息数据的持久化方案
3.5、确定环境部署和打包方案，在这篇文章中提到过现项目使用的docker部署微服务的pipeline构建的方式，所以该需求的构建方式也是一个docker微服务；
4、前段开发-位置信息显示、前段路径开发、前段电梯动画、前段状态信息显示开发、页面开发
5、后台开发-电梯运行状态推送接口、后台机器人位置推送、后台机器人状态推送、后台历史路径持久化-Redis、MongoDB功能封装、历史路径查询接口、Nginx配置部署、其他常规接口开发；
6、测试-编写测试功能点、评审测试功能点、测试用例
7、提测-版本构建、数据库sql语句，前后端版本保持一致；
8、执行测试：测试过程值得说一下，其实很多时候在评审需求、编写功能点的时候还是有很多细节性问题没有考虑到的，只有测试执行过程中才能发现问题。
在测试过程中发现遗漏点需要及时去找对应人员去沟通的，主要是管需求的经理，还有相关的开发、测试人员等干系人员。在现项目中，我们使用的是敏捷开发，工具是微软的Azure Devops工具，
需求在这个工具里面叫做US-用户故事点，也没有对应专职管理需求的产品经理，US都是开发、测试、master-敏捷教练轮流写。在这个过程中都会出现需求不明确、不细致的地方，需要在这个过程中
不停的去确认需求、修改功能点及测试用例；每日有对应的测试报告输出，尽管敏捷迭代中每天早晨的站会都是灵魂三连击：我干了什么、我即将干什么，我有什么问题；
9、测试报告，需要在敏捷开发的每个迭代结束时出具相应的测试报告，每个迭代为期两周，报告的出具比较简单，因为每个迭代时间是有限的，主要就是用例统计、bug统计、问题遗留等模块；
很多细节性的东西就不在这儿展开了，常规性的细节问题都是我们在整个软件生命周期中长遇见的那些问题。主要是记录一下敏捷开发中整个软件实现的大致过程；
