瓦力2.0|瓦力2.0 回顾总结瓦力2.0回顾总结

文章图片
为交付保驾护航, 提高交付效率愿景回顾

让研发只需要关注于自己的代码, 让产品只需要关注于自己的产品.
瓦力发力为国内机票研发,测试以及产品经理,提高研发主导在生产交付过程中的交付效率.

重视原则

在反复的代码修改及测试的过程中, 避免以下问题:

避免代码未合漏上线.
避免代码未测带上线.
避免上线未代码同步.
避免上线非所测代码.

能够提高协作效率, 降低沟通成本:

在协作过程中, 以过程引导的方式进行一站式操作.
在沟通过程中, 能传递信息的过程中到达快速,准确, 清晰.

过程回顾 1. 瀑布转敏捷瓦力项目经过系统设计和拆分以瀑布流方式进行推进.逐渐变成敏捷方式, 需求变得越来越不明确, 需求变得越来越零碎.
2.从敏捷转测试驱动 【瓦力2.0|瓦力2.0 回顾总结】项目初步交付后, 在实际打样过程中, 问题很多, 此时, 我们的开发流程变成测试驱动式开发.以修复错误及优化为主.
在过程中的遇到的问题, 不足之处, 改进方法主要问题出现在: # 需求管理# , #产品设计# ,#系统设计#, #质量管理#
案例分析: 1. 需求的变动与反复,

代码合并对其他工单的影响, 是否能让用户可以接受.
测试节点, 用户对测试节点的需求广泛. 一方面, 我们需要管控测试, 一方面我们需要放开测试. 对我们系统能够[保障上线代码必定已经测试过]的原则进行挑战.
发布申请节点及正式上线节点, 提供后悔的功能. 我们对国内机票内部发布管理的过程太过于理想化, 竟然到了已经申请的那一步了, 还有掉队的工单才来合并.

2. 不可预期的需求:

新增 [自动新增工单]节点
两个月后, 对这个[自动新增工单]节点, 用户要求的场景有变动, 我们不得不进行修改.

3. 对用户进行工作的过程缺乏足够的用户调研:

国内测试人员视角. 测试人员真正就是要只关心测试, 却花了很多时间到流程上去了. 瓦力任务的协调与跟踪本身就是该瓦力自动的事情.
国内项目群组管理员视角. 我们项目进行的进度是什么?报表一直是个不重视的一块.
研发人员视角, 真正需要关心的是什么? 真正需要操作的是什么? 能不能再少一些打扰, 少一些操作.

4. 部分过程性操作对用户应当无关:

代码合并过程, 修改为一键合并, 自动适应不同因素带来的情况, 由系统进行决策,而不是系统反馈给人进行决策. 后端研发人员以此为例, 设定不同因素不同策略规则,做到用户只要一个操作, 也只要一个结果,那就是执行成功与系统无法自动处理的执行失败.
构建部署过程, 同代码合并过程一样, 用户真正需要最直接的结果就是部署成功与失败. 要先构建才能后部署,只是系统内部的一个流程罢了.

5. 已经经过测试, 上线之后依然问题不断, 反复修改返工, 导致项目周期成本上升:

需要考虑到测试用例覆盖率. 比如新增GIT项目模块,缺乏了对不同类型项目的测试, java项目也进行新增构建结果的webhook接口调用, 导致java项目无法新增.项目无法新增, 导致项目无法使用瓦力, 甚至违背了瓦力提高效率的初衷,适得其反.
需要进行单元测试. 对固有对外integration层需要维护好单元测试代码, 确保长期integration稳定.对外部提供的服务,要保持怀疑的态度,不能过于相信其质量.
修改一个bug, 导致了另外一个曾经发生过的bug. 我们对于以往已经发生过的bug, 缺乏有效的跟踪机制, 并且需要冒烟测试和回归测试. 经过排查, 也是因为代码质量太差导致, 代码可读性及可维护性比较差, 比较重的地方, 就容易产生错误.

6. 性能不足导致的返工:

使用Job架构来消费工单因代码变动而回退的机制,这点经过了返工.
Web 页面使用定时器来刷新, 导致Web内存溢出. 用户在长时间打开着相同页面的时候, 会让浏览器内存不断上升, 最后不得不重启浏览器. 比如: 工单处理页面.
对技术要求要有量入未出的思考, 我们不仅仅需要考虑产出与投入的关系, 有时候, 成本可以降低到能解决问题的程度, 也隐藏着要返工的风险.

7. 线上故障,缺乏有效的引导:

当线上出现非系统导致的故障工单时候, 能让用户得以理解问题, 是什么问题导致,将会有效避免问题, 将会更加有效的提高工作效率, 而不是一脸懵逼的请求删除工单.
提交错误的时候 , 沟通难度大. 应该能让用户了解我们要通过错误页面的链接来有效排查问题.

8. Bugfix 流程是目前用户吐槽的高灾区:

Bugfix 流程设计缺乏了必要的研究, 在确定方案的时候, 没有准确进行研究, 而是空口跟了祥富确定了方案, 这块是不可取的, 我们需要用数据来模拟真实上线后的场景进行权重.

改进措施:

在需求分析上, 时刻和用户保持沟通,了解客观场景, 不以用户意识为首, 不以主观意识做决定, 而以客观世界的真实问题得以有效解决为主.
在需求管理上, 以需求分析留下过程性资产. 需求管理可以进行跟踪,分好轻重缓急.并做好可预期需求的规划.

文章图片
产品设计,系统设计更贴近需求

产品设计充分考虑调研用户体验,考虑用户处理效率.

按钮上让用户最少操作得到最优结果, 系统能自动化策略进行的就自动化, 减少人机交互.
界面上, 以用户视角为核心考虑, 不同角色真正需要的东西是不一样的, 不同场景下, 需要的也是不一样的. 以不同角色和不同场景做界面设计分析. 留下过程性分析文档.

在系统设计上, 提高重视需求贴近程度.

技术与需求不分家, 架构设计尽量贴近需求进行设计, 贴近现实场景, 保持扩展性和可修改性. 对隐藏需求和可预期需求要重视.
架构流程设计留下设计文档(流程图, 架构图), 说明设计原因,及优劣所在, 为满足的需求是什么, 可满足的隐藏需求和可预计的需求是什么 . 对未来不可预期的需求留下充分证据.

文章图片
质量管理优化

质量管理缺少跟踪

在瀑布,敏捷,还是测试驱动的过程中, 我们都出现了质量问题, 管理优化意见如下:
- 验收管理, 需求与实际不一致, 没有及时得到复盘. 后续跟进需求变现不一致问题需要跟进. 在需求管理需质量管理中得到关联记录, 及时总结问题所在.
- 缺陷管理, 缺少应有的详细记录, 包括复现步骤, 后续建立缺陷管理记录以进行系统冒烟测试, 回归测试.
- 用例管理, 内部团队在测试系统模块的时候, 分别依照需求进行编写测试用例, 依照缺陷编写测试用例.

在过程中的优点, 持续发扬在瓦力开发过程中值得肯定的点主要在与#放低姿态#,#用户体验#, #故障修复#

对用户的姿态放低, 更加注重用户体验.对用户更加尊重, 渐进的我们在不断寻求用户的口碑, 用户的痛点. 有了这个姿态是做出好的产品的前提.
故障处理效率上得到很大提升, 线上出现BUG相关工单能够及时得到响应处理是值得肯定的. 但是在系统设计上 , 应该主动避免问题的发生, 并且能够部分引导用户如何解决问题.
团队在技术能力逐步提高. 但依然不足,依然需要刻苦努力.