> # 一、可视化什么？——可视化照亮问题所在  能够看见的地方，却不是 “关键” 所在，当然也找不到需要的答案，研发过程当中，我们是否会范同样的错误？很不幸，不但会，而且还非常普遍  在软件产品的研发过程中，其实根本问题从来都不是停滞的资源（工程师），而是停滞的产品需求（用户价值）。 研发过程可视化，就是要可视价值端到端的交付过程，让我们看到价值流动的过程，以及流动过程中的阻碍、停滞和问题。  “开发中”的需求和其下属的任务处于同一行，我们称之为“需求泳道”。某个需求下属的所有任务都 “完成”后，则需求开发完成,可以继续往后流动到“待测试”，任务则可以清理或折叠。泳道空出，可以准备让下一需求进入。 通过这个看板我们可以看到需求流动的整个过程，看到需求被拆分成多个任务以及团队协作完成任务的过程。它帮助团队暴露和发现问题，促进团队更好地协作交付需求。为团队的高效协作和价值的顺畅流动奠定了基础。 > # 二. 如何可视化——四个步骤实现有效可视化 ## **第一步：用户价值驱动，识别有效的流动单元** 我们首先需要分析的是：团队或组织对外交付的是什么，从而识别有效的流动单元，明确可视化的主体。  以上四类需求是团队需要交付的主体内容，也是看板上的流动单元 ## **第二步：前后职能拉通，定义端到端价值流**  需求从（被）“选择”开始，经过“分析”、“待评审”阶段到达“就绪”阶段（注：就绪指的是对开发团队而言的就绪）；再经过“实现”、“待测试”、“测试待发布”，最后到“已发布”阶段。这个端到端的过程就是需求交付的价值流 端到端的价值流动过程,涉及不同的职能，如产品设计、交互视觉、开发和测试等。为了提升流动效率，必须拉通组织中的各个职能，实现整个过程的可视化 一些团队因为条件约束，无法立即做到全面的端到端拉通。条件允许，还是要尽量向两端扩展，才能实现真正的端到端的敏捷和精益。这也为团队的进化提供了方向 ## **第三步：左右模块对齐，体现环节的任务协作**  上图中间的“实现”阶段中，绿色卡片所代表的需求被拆分成多个任务（黄色卡片）。这些任务，分属后端、iOS 开发、安卓开发以及外部依赖等。团队的目的不是完成更多的任务，而尽快交付需求。 这就是我们说的：左右模块对齐，也就是任务向需求对齐，尽早交付需求。它促进团队以需求交付为牵引，更有效的协作，并帮助团队发现影响需求交付的瓶颈。 ## **第四步：明确流转规则，赋能团队本地决策、内建质量** 定义需求向下一阶段流动所必须满足的条件。比如:达到什么条件才能从“待评审”进入“就绪”环节。团队应该定义明确的需求流转规则，并达成一致理解 明确流转规则帮助团队做到内建质量。所谓内建质量，是让需求在每一个阶段的质量，都得到有效地保证，避免问题在最后的阶段集中爆发，和避免不必要的返工，这也是持续顺畅价值流动的基础。  下面的例子。就绪队列准入规则: 1. 开发、测试和业务共同澄清需求，并定义明确交互过程和验收标准 2. 大需求已拆分为工作量在两周以内可以完成和交付的需求 3. 已与业务关联方（如有）确认相关计划 4. 识别大的技术风险并定义应对方案 5. 涉及三个（含三个）开发人员以上的需求，指定好协调人，负责进度协调 ## **总结 - 可视化价值流的基本步骤**  ## 可视化是手段，而不是目的”。让价值顺畅高质量地流动才是目的