按需交付价值

3月30日，我参加了2019规模化敏捷春季峰会。此次峰会打破了以往“讲师在台上讲，同学们在下面听”的传统模式，以小组讨论的形式提出了13个非常有意义的话题，分组讨论。而我作为Topic Leader组织小组讨论了一个非常有趣的话题：Cannot release value when customers need it.（无法按照客户需要的时间点提供价值）。

这个话题实际上刚刚在我的项目中发生了真实的一幕，因此我把这个话题设定在这样一个场景：我们的团队正参与一个政府大数据分析的项目，该项目为政府提供诸如：风险防控、宏观分析、企业画像等服务。我们制定了一个为期4个迭代的PI Planning，每个迭代2周。团队正有条不紊地进行到第二个迭代，一个突发事件打乱了一切：

这天早上，一个来自客户的电话打破了清晨的宁静…

客户：赵总，最近项目进行得怎么样了？

PM（产品经理）：哟，张处，早上好啊！我们的项目进展顺利，上周已经交付了一部分功能了，周五的时候还跟小李过了一遍，他感觉还行。

客户：赵总啊，我们这个项目现在形势不错，得到了上面领导的高度重视。下周有高层领导要过来视察，期间要演示这个系统。这可是一次难得的机会，我们一定要好好把握。

PM（产品经理）：好的，张处，我们一定全力以赴。

客户：我了解了一下，领导更关心的可能是宏观经济分析，特别是城际贸易那部分。你们能不能调整一下计划，这周把城际贸易那部分先开发出来？

PM（产品经理）：好的，我落实一下这个事情。

随即，PM（产品经理）组织了一次紧急会议，把各干系人都召集了起来。情况跟大家一说，随即炸了锅。按照计划，宏观分析团队的城际贸易分析功能是在下一个迭代完成的工作，就意味着不得不进行backlog优先级的调整。并且，宏观分析团队必须在迭代的第一周就要完成城际贸易分析功能，并且能够交付用户，这无疑是一种挑战。

PM（产品经理）：大家别吵！我们把backlog优先级调整一下，把城际贸易分析调整到前面来先做不就行了嘛！（PM不以为然地说）

RTE（敏捷发布火车工程师）：调整backlog优先级说起来容易，做起来却不是那么简单。

宏观分析团队也急了：一周就完成这部分功能，时间太紧了。开发都来不及，更别说测试了。

DevOps工程师：不是说好2周一发布吗？1周一发布，其它团队怎么办？我可不敢保证！

风险控制团队也来凑热闹：按照PI Planning，宏观分析团队这周可是要给我们提供几个数据模型的！如果他们提供不了，我们这个迭代周期的好多功能都不能交付哟！

看看，多么熟悉的场景，这样的场景相信许多的团队都经历过。面对用户的变更，过去我们试图用合同与管理去“堵”。然而，在快速变化与激烈竞争的今天，这种“堵”的方式已经不再奏效，因此我们开始敏捷，开始拥抱变化。然而，当我们真正敏捷起来的时候，当我们开始迭代，开始Scrum，开始XP的时候，开发组织形式的改变是不是就一定能拥抱变化呢？现实却不是那么简单。

现实的情况就是，市场的机遇稍纵即逝。软件开发一方面强调计划性，有条不紊地组织开发，然而，另一方面又要强调快速应对变化，快速抓住市场机遇。这时候，快速交付与耗时就成为一对尖锐的矛盾。如何解决这对矛盾呢？SAFe规模化敏捷给了我们答案。SAFe原则第一条“用经济的视角去思考问题”告诉我们，只有快速交付才能经济利益最大化，而完成用户所有需求是不可能快速交付的，因此应当先交付用户价值最高的部分，再按照用户价值高低逐步交付用户价值。理解这一点对于PM（产品经理）甚至更高层的BO（业务负责人）显得尤为重要。一周时间交付所有用户价值是不可能的事情，哪怕是加班。无节制地加班只能使团队工作效率与设计质量低下，为项目埋下更大的隐患。那怎么办呢？为需求划分优先级是更加可靠的一种思路。在这个案例中，城际分析这部分功能要完全做到位，一周时间很难完成。然而，客户需要的不是完全做出来，尽善尽美，而是有一个能展示、能分析地这么一部分功能。因此，在遇到这种场合的时候，作为决策层的PM（产品经理），不能慌，要冷静。冷静地与客户去探讨当前的形势，什么对于客户是最重要的，什么是次要的。将最重要的用户价值先做，把时间用到刀刃上，快速交付用户，赢得市场价值。

图1：灰色的柱子代表更快交付的用户价值

当我们完成决策以后，是不是团队就能够拥抱变化了呢？理论上可以，现实却很骨感。我们为什么说要持续改进，就是要逐步打造一支能打仗，打硬仗的团队。而这不是说说而以，真正要落实到行动中。快速变化，首先要求的是团队具有快速交付的能力。从需求分析、设计开发、测试，一直到交付用户，就像一个管道。产品研发在这个管道中流动的速度，是由管道中最窄的部分，即流动最慢的部分决定的。因此，我们的交付速度，与团队的组织能力、团队成员的开发能力、系统架构的支撑能力、软件质量的保证能力，以及最终发布能力，每一个环节都息息相关。任何一个环节做得不好，都会影响最终的交付。

先来说说团队成员的开发能力。每个软件从上线之日起，之后整个生命周期其实都是在不断地变更，而敏捷开发的变更速度会更快。在敏捷开发团队中，每1-4周一个迭代，每个迭代都是在上一个迭代的基础上变更代码。而在传统的开发团队中，每次变更就会带来代码的退化。因此，在敏捷团队中，如果不能很好地保证每次变更的代码质量，则代码退化的速度会更快。代码的退化带来变更成本的增加和变更周期的变长。因此，没有代码设计质量作为保证的敏捷团队是没法保证快速交付的。那么如何保证团队成员的设计质量呢？除了持续地学习高质量代码设计知识、持续改进以外，还需要学习一种叫做“小步快跑”的开发方式。关于“小步快跑”的开发方式，我会持续与大家探讨。

接着是系统架构的支撑能力。对于一个能够快速交付的敏捷团队，它的组织形式必须是特性团队，即团队的任务分工都是面向终端用户的某个特性的。这种组织形式，当我们捕获了用户需求的多个特性时，总是趋向于将某个特性交给团队某个成员（或某个团队）去完成。该成员（或团队）为了完成这个特性，从UI到应用，一直到数据库设计，都尽量是自己去完成。这种分工形式保证在完成某个特性时，尽量减少协作与依赖，从而降低沟通成本，提高交付速度。但这种分工形式，除了对团队成员提出更高要求以外，更多地是要求整个系统架构具有更强的支撑能力，支撑特性团队以更低成本、更高效率和更快速度开发系统，并将更多精力放在业务逻辑而不是技术实现上。在SAFe中关于平台架构的建设是通过“架构跑道”与“使能故事”来进行的，这方面我也会持续与大家进行探讨。

除此之外，在短短1周时间开发与交付，还能保证代码质量，这依赖的是内建质量，即质量的保证不是在最后的测试，而是在开发中的一次次编码来保证的。内建质量（Build-in Quality）则需要团队成员通过持续改进，逐步建立起“小步快跑”、“测试驱动”等设计能力。

以上探讨的都是提高单个团队的开发能力。然而，在软件规模化发展越来越明显的今天，由多个敏捷团队组成的规模化团队越来越成为主流。如果敏捷团队是李云龙的独立团，那么规模化团队则是集团军，其战略战术都将会完全不同。因此，在规模化团队中，一个团队的计划变更，必然会影响到多个团队，就不再是改改backlog优先级那么简单的事情。那么，在规模化团队中如何有效地拥抱变化，降低团队间耦合度是其中一个思路。在规模化团队中，以特性团队组织，就会尽可能地将某个特性交给某个团队来完成，从而降低耦合度，提高交付速度。但是，尽管开发的速度提高了，各个团队还是统一打包交付客户，就会带来团队间的部署依赖，降低交付速度，即开发速度再快，交付速度上不来依然没用。所以，随着团队规模越来越大，日后越来越多的系统架构必然向微服务转型。

图2：每个特性团队各自独立发布各自的微服务实现快速交付

只有团队开发能力提高、内建质量提升、系统架构支撑、微服务与DevOps的转型，才能打造一个特别能打硬仗的队伍，越来越快速而灵活多变地交付用户价值。而这个过程需要所有团队持续改进，不断提高。