【读书笔记-007】持续交付2.0之快速验证环

2019-03-02 本文已影响41人爱倩子的李总

团队经历了”探索环“之后得到最小可行性解决方案，需要通过”快速验证环“的快速运转得到可运行的产品或者服务，交付到用户或者客户手中，根据真实可靠的反馈来评估最小可行性解决方案的价值。

团队创建的产品或者服务在真正被用户使用之前，我们只能衡量成本，只能评估价值；只有在真正被用户消费和变现，才能证明其是有价值的存在。

快速验证环

验证环的目的

借助各种工具和方法将探索环得到的最小可行性解决方案以最快速度和质量可靠地到达客户手中，并收集得到客户的真实反馈以验证最小可行性解决方案的过程。

构建环节将探索环得到的需求，通过需求拆分、编码、测试、版本验证、质量问题修复、软件包构建等步骤得到计算机可运行的软件，即”质量达标的软件包“。该环节呈现出”不确定性“的特点，一直是软件工程领域的一个重要问题。时间盒管理、任务拆分和持续验证是这个过程中重要的方法。

时间盒管理：涉及交付物、交付质量和截止时间，通过建立这种项目管理方法，项目经理可以实时了解当前项目的进展和质量情况，及时发现风险并制定对策。
任务拆分：包括两种，1）对需求的拆分，对探索环得到的最小可行性解决方案中的需求进行拆分，分解成更细粒度的子需求，建成一个story或者task；2）对开发任务的拆分，为了实现某个需求，将其分解成多个开发任务，每个开发任务由一个人完成。
持续验证：每一项开发任务完成都需要立即对交付质量进行验证，而不是等待多个需求完成后再进行大批量的质量验证工作。

将构建阶段的软件部署至生产环境，并让它提供服务，并且要求不能影响到用户的正常使用，在用户无感知的情况下完成版本的升级更新是互联网时代中极其重要的问题。

负责数据的采集，并展示统计结果、及时发现生产系统问题以及业务指标波动，做出适当的反应。确保数据的有效性和可靠性是这个环节需要关注的问题，因为会直接影响到后面的决策方向。团队必须在验证环一开始就确定好数据需求，并随着正式的需求同时上线。

根据采集到的业务数据反馈后，根据探索环中已确定的相应衡量指标进行对比分析，从而验证是否满足当初的预期。通过分析数据背后的原因，最终确认原来定义的需求假设是否都成立，并决定是否坚持原有的产品方向，还是做出调整。

主要包括：质量内建、消除等待、尽量并行、监控一切。

质量内建：传统的瀑布开发模式强调每个阶段的输入输出质量，等到进入正式的继承测试阶段才将所有的代码合在一起运行，导致发现软件问题的时机太晚，对这些缺陷修复的成本也很高；质量内建就是从生产过程的第一个环节开始就要注重产出物的质量，每个环节每个迭代都要对质量保障，尽早发现问题并降低修复质量问题的成本，保障进度。
消除等待

通过pull让价值流动起来：识别整个交付流程中的瓶颈，关注每个需求的状态；
1）一旦某个环节出现的阻塞，就需要扩大瓶颈的处理能力，比如可将开发人员暂时投入测试，临时增加测试人员，达到整个系统的最大化产出；
2）基于pull的思想，从整体系统出发，应该根据下游的生产能力来确定上游的生产速度，下游拉动上游的需求，让整个环节顺利通畅；尽量让每个需求分解成工作量相近的小需求。
一条道路，如果只有小轿车，道路会非常通畅，但如果大货车与小轿车混行时，道路的通行能力就会下降了。
3）将开发人员的过剩人力投入到平台建设，提升下游的基础能力。
任务自动化：关注工具平台的建设，将一些可自动化的操作任务化和自动化，比如环境的部署、数据的统计和展示等，不需要依赖负责人，每个人在需要是通过”自助服务“自行完成重复性的操作。

重复事物自动化：软件研发过程中的重复性工作，比如环境搭建、回归测试、应用部署和发布等，交付频率的提高会提升手动维护的成本，通过优化流程和自动化，可以降低固定事务性的成本，也降低了快速发布带来的成本问题。
监测一切：监测环节，需要能够及时准确地收集并分析数据，不仅要确认软件的正常运行，称为”应用健康监控“，也要及时得到有效的业务数据，称为”业务健康监控“。

到这里双环模型的探索环和验证环就总结完了，这两个环是相辅相成，不断促进和循环的，探索环的精炼环节得到的最小可行性解决方案，通过验证环的验证，经过决策环节确定的方向，重新走向探索环，共同促进了产品和服务的高质量快速的持续交付。