训练营往期回顾:Day Zero – 开通效率云服务 <<

Day One – 使用iCafe进行敏捷项目管理 

今天的课程分为理论和实操两个部分, 理论部分我们会介绍:

– DevOps和敏捷开发的联系

– 用户故事地图

– 研发价值流

实操部分我们会使用iCafe绘制一张属于你自己产品的用户故事地图，配置你团队的研发价值流，定制你自己团队的效率度量。下面正式进入我们第一天的理论课程:

理论部分1: DevOps和敏捷开发

DevOps 提倡使用敏捷开发做为开发过程，是因为二者提倡的理念较为一致,即: 小批量的，尽可能频繁的交付价值以获得快速的反馈。敏捷开发的一系列管理实践帮助团队有效的识别真正的用户价值，并且能够帮助团队实现快速的资源聚焦和调整，同时DevOps通过引入大量的工程实践，先进的基础设施和工具又为敏捷开发理念提供了可靠易用的工具链。可以说二者结合在一起，才能真正发挥一个研发组织最大的潜力，真正实现持续向客户交付价值。

我们可以通过下面的图表简单的说明敏捷开发的管理实践在DevOps整体实践中的价值:

效能&效率

敏捷，以及精益开发中的系列管理实践，如商业画布，客户开发方法，用户故事地图，Impact mapping都在尝试帮助团队在决策阶段解决一个核心问题: 什么是用户价值，如何识别当前最重要的用户价值，团队如何快速的聚焦资源投入其中。我们可以把这部分的工作称之为Do the right things；

一旦进入到执行阶段，DevOps中提倡的快速反馈帮助团队识别研发过程中的浪费，通过一系列的管理和工程实践来消除浪费，提升团队的交付效率，真正实现随时发布。我们可以把这些工作称为Do the things right。

只有二者相结合才能真正持续快速交付有效的用户价值，单独实施其中一种虽然可以为企业在效能，或效率方面一定的提升，但无法通过DevOps发挥组织全部的潜能。

理论部分2: 用户故事地图

在Scrum，以及kanban等敏捷开发框架中，产品backlog是一个重要的理念，他代表了整个产品或项目的待办条目。传统的backlog通常会以一个一维的列表形式展示，一般来说会包括优先级这样的重要字段。传统的backlog往往存在以下问题:

– 只见树木不见林，重要的待办项容易淹没在各种细节中看不到全貌，因而难以排列优先级

– 不能明显地聚焦于用户需求

– 很难了解不同粒度故事(史诗故事、主题故事以及故事)之间的关系

– 不能方便地了解系统提供的功能的完整性

– 不能方便地了解系统提供的工作流以及价值流

– 不能方便地利用递增和迭代的方式去确定发布计划以及发布目标

常见产品backlog

用户故事地图提出了一种以用户体验路径为视角建立需求的方法.团队通过对用户的画像，具体场景的讨论，快速就产品需求达成一致, 如下图所示:

用户故事地图示例

这是基于效率云的产品规划功能建立起来的用户故事地图，第一行我们在百度内部通常称之为用户场景，第二行是用户在此类场景下可以从事的一系列任务，在百度内部我们通常称之为feature，从第三行开始是一个个具体的用户故事，即user story。在建立用户故事地图的时候，有两个默认的习惯: 1. 从左到右按照用户使用产品的体验路径进行书写；2. 从用户故事开始，从上而下代表需求的优先级从高到低。

理论部分3: 研发价值流图

价值流程图（Value Stream Mapping，VSM）是丰田精益制造（Lean Manufacturing）生产系统框架下的一种用来描述物流和信息流的形象化工具。VSM可以作为管理人员、工程师、生产制造人员、流程规划人员、供应商以及顾客发现浪费、寻找浪费根源的起点

David Anderson 在他的《看板方法》一书中提出了还原软件开发过程中的价值流图的方法– Mapping the value stream; 即通过可视化的看板最大程度的还原团队的开发过程，再通过缓冲区，限制WIP等手段帮助团队发现浪费，寻找改进的机会。

笔者在百度内部曾使用价值流图为多个产品研发团队进行研发效率的分析，下图是一张真实团队的价值流图。从这张图最终的统计数字可以看出，这个团队在单个需求的交付过程中，只有37.5%的时间在进行有效价值的累积(访谈客户，撰写需求，Coding), 其它时间都在进行与输出用户价值无关的工作。它包括了几个重要的元素:

1. 价值流的生命周期-- 下图是以一条需求从诞生到发布做为价值流的起点和终点；

2. 每个阶段的具体任务及关系-- 我们可以看到白色卡片是研发每个环节的具体任务，以及串，并行关系

3. 每个阶段的耗时-- 在图的最下方，按照增值，非增值，非增值但必要将所有的任务进行分类，并统计耗时，最后用增值部分耗时/总时长计算出整个价值流的流动效率, 即右上角显示的 37.5%。每个团队可以根据自己的实际情况来划分增值，非增值任务，但总的来说，增值部分的任务不应该超过所有任务的20%

4. 研发过程中的7种浪费-- 右下角的图例为精益生产中的7种浪费映射到研发过程中的现象，方便团队对研发过程中的问题进行系统性的分类

5. 在具体任务中发生的浪费及耗时-- 团队成员对着价值流图，通过情境的回溯，将每个任务过程中发生浪费的原因列举在上面，做为需要改善的现象

真实的研发价值流图

绘制一个价值流图的步骤如下:

识别生命周期，划分阶段

阶段向下分解，成为具体任务

收集执行时间，识别浪费

计算价值流的流动效率

以上就是今天课程的理论部分，对于用户故事地图，研发价值流感兴趣的同学，可以购买书籍进行自学，或联系笔者进行深入讨论: