与传统的项目管理不同，敏捷项目管理关注价值。
要理解价值，我们先要理解项目的目标是什么，无外乎包括以下几个方面：
明确了目标，再来谈价值。价值从本质来说，代表的是所提供的产品或服务对最终用户的价值，即用户愿意支付的、最终对于企业本身产生的增值，而不是仅仅被企业所认可。
举个例子，银行在线上提供个人自助贷款服务，其目标是在3个月内线上个人贷款业务数达1000笔，贷款总额达5000万元，新增线上用户数达3000个。对应到价值，可以理解为更高的销售额、更多的利润以及更多的用户。
相比传统瀑布开发，敏捷是对软件交付价值链的系统性颠覆。价值链上游的产品需求从庞大完整的功能版本以一定的优先级次序被拆分成了源源不断的故事卡。上游需求单元的颗粒度和频率变化让交付环节的管理复杂度指数级增加，项目经理应改变“项目是为了交付更多功能”的传统观念，而把关注点放在“这个功能有什么用”——即项目交付的价值上。
如何交付价值呢？
不同于传统的瀑布开发模式，敏捷软件开发以迭代的方式进行，旨在不断收集真实用户反馈、听到市场的声音，践行价值交付。
通过敏捷项目，让我们“想象”中的“价值”更快地交付到市场，以验证其是否真有价值。一般而言，敏捷软件开发会将每次的发布（Release）分成多个迭代（Iteration），在每次迭代结束都会做showcase，演示本迭代开发功能。项目经理需要从价值交付的角度管理每个迭代的需求，让每次showcase都能展示有“价值”的功能。
为了达成目标，在项目交付中，我们需要对价值流作出行之有效的管理。
项目经理如何改善价值流呢？
知易行难啊...现实是：
在制品（Working In Progress，WIP）数量增加
系统前置时间（System Lead Time）变长
本着信息透明的原则，先用“看板”来限制在制品。如下图所示，通常我们都是采用基于“列”的在制品限制。
通过对看板流转情况的动态观察，识别影响看板的瓶颈，从而通过限制在制品避免和解决瓶颈。比如，我们发现在测试阶段（Testing）出现任务的挤压，这时候测试就成了整个看板的瓶颈。那么我们有可能采取的方式是：增加测试人员；或限制测试任务的输入，即在开发阶段（Development）限制在制品。
在项目的前期，在制品数值应该是经常变动的。分享一个快速设定在制品数值的方法：
如果某列经常同时有5-6个工作在进行，我们最初可以将在制品数量限定在10-12个，然后规律性的以20%的幅度将其递减，继而达到一个相对稳定的值。在制品数值的调整，本身也是一个持续改进的过程。基本原则是避免浪费，提高效率。
项目经理还要时刻关注System Lead Time。
Lead Time升高的原因有很多，不同问题采取不同的对策。
如果是组织和环境（流程与协作、质量与基础设施以及组织方式与技能）的原因，可以考虑通过改变“游戏”规则的方式来得到期望的结果。举个例子，有些团队在项目初期从需求分析到制定各种计划，通常一周时间已经过去了。然后再作需求评审，又需要两到三天时间。为了缩短Lead Time，我们需要改变“游戏”规则：简化流程，优化系统。如果是风险管理（技术、业务和依赖关系）出了问题，则需要通过加强风险管理的手段来预防和管控。
在软件开发中，价值流的直接体现是从想法和假设到软件功能上线并产生客户价值的过程，研发效能的本质是持续的价值流。如何度量研发效能呢？4 Key Metrics来帮忙。
在ThoughtWorks2019年4月的技术雷达中如是说：
我们已经发现这四个关键指标是个简单却强大的工具，可帮助领导和团队专注于衡量并改进重要的环节 。实施构建流水线是一个良好开端，以便你能够捕获四个关键指标（Four keymetrics），并使软件交付价值流可见。
打破研发和运维的墙，快和稳通盘考虑，这是4 Key Metrics给我们的第一个启发。
第二个启发：关注指标的变化，分析其变化的原因，以此来牵引团队研发效能的提升。
第三个启发：能够让团队的技术治理更有方向性，如果某项技术治理对于快和稳没有帮助，那么说明团队投入的工作量没有给客户带来价值，这样的技术治理很有可能是自嗨。
软件开发流水线和任何复杂精巧的人工机制一样，构建十分困难，摧毁却又十分容易。能够直接体现业务价值的指标和数字往往是最具说服力的，关注指标的变化，分析其变化的原因，4 Key Metrics是呈现价值的重要方式。
项目经理最主要的任务是和团队一起交付价值，为了实现这个目标需要做很多事情。项目经理很不容易，我们要多关心他们。
后记
两年前在写《项目管理中的敏捷实践》时，对交付价值的理解并不十分深刻。很多时候，我们都能理解敏捷的实践，却忽视了敏捷的本质。敏捷的本质正是追求价值，这也是我们很多软件从业者的初心。
本文从构思到成文花了一番功夫。我希望用更为简单、生动的表述方式，因此采用了许多自己设计的图画。限于我的构图水平，还有很多瑕疵，但希望画尽其意。谢谢阅读。
本文作者万学凡，ThoughtWorks首席咨询师，武汉。作者保留本文一切权利，未经许可请勿转载。
